Opened 13 years ago

Closed 12 years ago

Last modified 10 years ago

#1757 closed defect (wontfix)

Memory leak in dojo.js

Reported by: patrick.heymans@… Owned by: alex
Priority: high Milestone: 0.9
Component: General Version: 0.4
Keywords: Cc:
Blocked By: Blocking:

Description

Including dojo.js without anything else causes a memory leak of about 1.5 MB. Normally this is not noticed when you're using a single browser window, but our web application requires opening of child browser windows. The following HTML may help to reproduce this problem. Simply click on the link a number of times to open child browser windows and close them.

Hopefully you can squeeze this in your tight 0.4.1. schedule because this one is very important for us ;-)

  <script language="JavaScript" type="text/javascript" src="../js/dojo-0.4.0-widget/dojo.js"></script>
  <script language="javascript">
    function dlgOpen() {
      var dlg = window.open("openwin.html", "dlg");
    }
  </script>
  <a href="javascript:dlgOpen();">Open Window</a>

Attachments (1)

openwin.html (506 bytes) - added by patrick.heymans@… 13 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 13 years ago by bill

Owner: changed from anonymous to alex

comment:2 Changed 13 years ago by alex

Priority: highnormal
severity: criticalnormal
Status: newassigned

peak memory usage !== leakage. It's not clear from your example that you're actually describing leakage or that it's caused by Dojo.

Also, what browser? OS? Version?

We can't debug things until we get complete bug reports.

comment:3 Changed 13 years ago by guest

I'm using IE6 on Windows XP SP2. And I'm not talking about peak memory usage here. If I remove script tag that includes dojo.js, then I can open as many child browser windows as I want, and upon closing them the memory is fully reclaimed. However, by adding the script tag to include dojo.js you can see the memory grow by opening a child browser window. Upon closing these child windows the memory is NOT released, not even after a while.

comment:4 Changed 13 years ago by bill

You didn't attach openwin.html. What are the exact contents of the file? Just this?

  <script language="JavaScript" type="text/javascript" src="../js/dojo-0.4.0-widget/dojo.js"></script>

Changed 13 years ago by patrick.heymans@…

Attachment: openwin.html added

comment:5 Changed 13 years ago by patrick.heymans@…

I've added openwin.html.

I also checked FF 1.5 on WinXP and here is no leak noticable.

comment:6 Changed 13 years ago by Michael Schall

We open windows in iframes in floating panes or tab containers. I noticed the same issues with the memory loss. I have a little more control of when I'm releasing the iframe from memory so my close window looks like the following. Setting the src to about:blank will start the unload of the current page. Then I give the browser 3 seconds to clean up before releasing the iframe from memory. Not sure if this helps you at all, but without the clean up time I was seeing the same issue.

		destroyWindow: function(window) {
			with (window) {
				iframe.src = "about:blank";
				...
				this.domNode.removeChild(iframe);
				dojo.lang.setTimeout(
					function() {
						iframe = null;
					},3000)
			}
		}

comment:7 Changed 13 years ago by guest

Perhaps a solution could be to partially initialize dojo if it already was initialized in the top browser window. Performance may also benefit from this approach, but I'm not sure if something like the following is possible:

var dojo = top.dojo;
if (!dojo) {
  // do "normal" dojo initialization
}

comment:8 Changed 13 years ago by Michael Schall

I have found some leaks in my destroyWindow code on IE. removeChild is a bad thing... See ticket #1727

comment:9 Changed 13 years ago by alex

Priority: normalhigh

comment:10 Changed 13 years ago by alex

Milestone: 0.4.10.5

I just spent a couple of hours on this and I don't have a solution. I'm afraid I'm going to have to punt to 0.5.

comment:11 Changed 12 years ago by guest

We have exactly the same problem. It is critical for us because we implement a console which pops up forms. An operator may sit at the console for an 8 hour shift and open hundreds of windows over that period of time. The operator is running out of memory very quickly. This is an IT management application, and is very compromised by this defect. peter.houck@…

comment:12 Changed 12 years ago by James Burke

I made a test page for this that does not use any Dojo at all, and I still see a leak:

http://dojotoolkit.org/~jburke/trac1757/popup.htm

The popup window loads a simple.js that has the same var assignment over and over. But it still leaks. simple.js is about 2.6 MB.

So I think IE 6.0 is just bad at memory management with child windows (haven't tried IE 7 yet).

comment:13 Changed 12 years ago by hlprmnky{at}gmail.com

jburke, I owe you several beverages of your choice -- this issue turned out to be the culprit in a critical bug in my application, fixed just before the last ship to beta. :D

Here is a solution for the case where you want to submit forms from a popup window, presumably it would also work when you just want to close the window. :)

<!-- This block goes after your <script src="/path/to/dojo.js"></script> decl -->
<script type="text/javascript">
    var wakeUpIE = function() { dojo.event.kwConnect({srcObj: dj_global, srcFunc: "onbeforeunload", delay: 200, once: true, adviceFunc: function(){dj_global.location = '#';}} )};
    dojo.addOnLoad(wakeUpIE);
</script>

It might be necessary to do something additional to ensure that dojo.event exists before calling dojo.event.kwConnect -- I cannot get the above code to fail on my ma

comment:14 Changed 12 years ago by alex

Resolution: wontfix
Status: assignedclosed

sounds like James' resolution means that this isn't really a Dojo bug. I'm inclined to mark "wontfix" or "worksforme". Sucks about IE, and perhaps this should be documented somewhere, but it doesn't seem a Dojo bug and I'm not sure what Dojo could/should do to prevent it given James' test page.

Note: See TracTickets for help on using tickets.