JDK-4988299 : Memory leak when running java applets that communicate with javascript
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_03
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2004-02-04
  • Updated: 2004-04-28
  • Resolved: 2004-02-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2_05 05Fixed
Description
An HTML page uses JavaScript to load a Java applet on Netscape 7.0/Solaris. The webpage loads the applet and then proceeds to exhibit a memory leak which eventually (10-20 hours+) hangs the system.

Customer is complaining about the memory leak problem when running java applets that communicate with the java script. Customer mentioned that he is seeing this memory leak problem when using java plugin 1.4.2_02 with netscape browser 7.0 and he does not see the problem with IE 5.5.

When memory does get eaten up, it follows a saw-tooth pattern:  More memory is allocated.  The amount of free memory is a decreasing percentage of available memory.  When the amount of free memory hits a floor, it jumps back up to a percentage of available memory.  In general, when it jumps back up, it jumps to a lower level than it did in the previous jump (e.g., if it had 50% memory free in jump 1, in jump 2, it might only have 47% free).  This pattern continues until more memory has to be allocated. In customers testing, they saw 3520K of memory allocated initially.  This grew to 4400K in approximately 10-15 minutes.  When I stopped testing after approximately 3 hours, it had grown to 13544K.

Customer has considered several work arounds, such  as calling the applet's method from within the applet.  When they have done this test, they did not see the memory leak. 
However, this work around is not acceptable from their application's architectural point of view.  They have an architecture that uses the JavaScript - Java communication widely deployed.
###@###.### 2004-02-04
###@###.### 2004-02-06

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger-beta2 FIXED IN: 1.4.2_05 tiger-beta2 INTEGRATED IN: 1.4.2_05 tiger-b40 tiger-beta2 VERIFIED IN: 1.4.2_05
2004-06-14

EVALUATION I found one leak from Plug-in code about calling GetStringUTFchars without calling ReleaseUTFChars. However, based on the leak output from workshop, it looks like a lot of memory leak is caused by java font and VM. More investigation is going on. ###@###.### 2004-02-06 I think I found the ultimate reason of the leak. The problem is when Mozilla's JS calling to Java. It first grabs a java object. However, before returning that object reference to the browser, plug-in global refs it. This is done without notifying the browser. So browser think it is a local reference, so it global refs it again. At some point later, the js script engine running GC to garbage collect that global reference it creates, so DeleteGlobalRef gets called. But the first global ref never gets garbage collected. This will result the heap overrun and the program finally runs out of the memory and gets crashed. I am thinking a way to fix this. Change the status to FIP. ###@###.### 2004-02-12
2004-02-12

WORK AROUND Calling the applet's method from within the applet. ###@###.### 2004-02-04
2004-02-04

PUBLIC COMMENTS Customer is complaining about the memory leak problem when running java applets that communicate with the java script. Customer mentioned that he is seeing this memory leak problem when using java plugin 1.4.2_02 with netscape browser 7.0 and he does not see the problem with IE 5.5. When memory does get eaten up, it follows a saw-tooth pattern: More memory is allocated. The amount of free memory is a decreasing percentage of available memory. When the amount of free memory hits a floor, it jumps back up to a percentage of available memory. In general, when it jumps back up, it jumps to a lower level than it did in the previous jump (e.g., if it had 50% memory free in jump 1, in jump 2, it might only have 47% free). This pattern continues until more memory has to be allocated. In customers testing, they saw 3520K of memory allocated initially. This grew to 4400K in approximately 10-15 minutes. When I stopped testing after approximately 3 hours, it had grown to 13544K. Customer has considered several work arounds, such as calling the applet's method from within the applet. When they have done this test, they did not see the memory leak. However, this work around is not acceptable from their application's architectural point of view. They have an architecture that uses the JavaScript - Java communication widely deployed. ###@###.### 2004-02-04 ###@###.### 2004-02-06
2004-02-04