United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4988299 : Memory leak when running java applets that communicate with javascript

Details
Type:
Bug
Submit Date:
2004-02-04
Status:
Closed
Updated Date:
2004-04-28
Project Name:
JDK
Resolved Date:
2004-02-24
Component:
deploy
OS:
solaris_8
Sub-Component:
plugin
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_03
Fixed Versions:
1.4.2_05 (05)

Related Reports
Backport:

Sub Tasks

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
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
WORK AROUND

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

                                     
2004-02-04
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
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



Hardware and Software, Engineered to Work Together