412065 - Loading Java API Spec leaks memory

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect, P2)

Description

[Steve Chapel]

Attachment: testcase (loads API spec every 5 seconds)

This is a followup to bug 52658. Repeatedly loading the Java API Spec causes memory use and GDI object use to increase without limit. For convenience, I'm attaching a testcase that loads the page every 15 seconds. Overnight, it makes memory use go from 30 MB to over 100 MB and the number of GDI objects go to over 7000. I tested with Firefox 3 beta 2 on Windows XP.

Comment 1

[Steve Chapel]

Attachment: testcase (loads API spec every 15 seconds)

Comment 2

[Mike Schroepfer]

Is this with the new java plugin? 

Comment 3

[Steve Chapel]

Yes. I first saw the problem with Firefox 3 beta 2 and Java 6 update 3 plugin. I have also reproduced with Firefox 3 beta 2 and Java 6 update 10 plugin (the next generation plugin), and yesterday's Minefield nightly and Java 6 update 3 plugin. All combinations seem to cause similar memory and GDI object leaks.

Comment 4

[Steve Chapel]

Attachment: slightly reduced testcase for GDI leak

This is a slightly reduced testcase that reproduces just the GDI object leak. Each time you reload the testcase, it leaks two GDI objects.

Comment 5

[Cees T.]

Attachment 298720 [details] doesn't leak for me. And attachment 296696 [details] only causes 50+% CPU use on this dual core 3.2 GHZ P4 with 504 MB RAM. If there's any GDI leak, Task Manager isn't showing it.

Java 1.6.0_03-b05 on Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I can't reproduce the leak here either.  Reloading the page constantly does cause the GDI object count to go up, but that's expected -- those objects are released after about 60-120 seconds when we go through and do image cleanup.  (You can accelerate that effect by grabbing Stuart's RAMBack extension from AMO -- hit reload on the testcase a bunch of times, then hit the RAMBack button.)

This is without Java installed, though; but the last testcase definitely doesn't use java, and I'm pretty sure that the actual API reference doesn't either.  In both cases they're just loading an image.

Comment 7

[Steve Chapel]

I just tried again using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021104 Minefield/3.0b4pre and a new profile. Within two hours, memory use went up from 50 MB to over 100 MB and the number of GDI objects went up to almost 7000, using the first testcase. Are you both saying that none of the testcases cause any type of memory or GDI leak for either of you? That's very odd, because it's 100% reproducible for me on two different computers (one Intel Core 2 running Windows XP Pro with Firefox 3 beta 2 and one Pentium 4 running Windows XP Home with the latest trunk build and a new profile).

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ah, ok, so I can reproduce the GDI object count going up, but it's not a leak per se... hitting the ramback button or closing the page and waiting causes the memory/GDI objects to be freed.  So my guess is that we're reloading some image over and over, and for some reason our cache timeouts aren't triggering.  Stuart, any ideas?

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

What's happening here is that there's a 2x2 tracking image used on that page, with a dynamically generated URL.  Because the URL is dynamically generated, we cache a new copy of that each time.  And each image is tiny, so we never hit our maximum memory stuff for the image cache.  This will essentially go away once 415854 is fixed.  The memory and GDI objects should get freed if normal browsing continues, because larger images will cause all these things to get evicted from the memory cache.

Comment 10

[Mike Schroepfer]

Should we up the prio of that bug then?

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I believe this was fixed by the checkin for bug 415854.

Comment 12

[Steve Chapel]

After running the 5 second testcase for 6173 iterations (about 8.5 hours), the number of GDI objects is just 220. I conclude that the GDI object part of the bug is fixed. The build I tested is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre

On the other hand, the Mem Usage went from 67 MB to 177 MB, meaning that about 18 K of memory is still leaking with every reload. After closing the tabs that ran the test and opening a new tab and browsing around for several minutes, the Mem Usage did not go down.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I think I see a slight increase here, but after running the 5s test for about 2 hours and firing RAMBack, I don't see much of an increase over what we started at.  I'm pretty sure then that this isn't a real leak, though the particular case here is triggering some growth of a cache or something that's not being cleaned up as often as it should.

Comment 14

[Steve Chapel]

I can reproduce on Linux with Firefox 3.5.5. Running the testcase that loads the API spec every five seconds, I saw the maximum RES increase from 136 MB to 155 MB slowly and steadily over about three hours. This comes to about 9 KB of memory increase per page load.

Comment 15

[Benoit Jacob [:bjacob] (mostly away)]

Using Firefox 11 and about:memory?verbose I can't see a leak in the docs.oracle.com compartment. Memory usage, especially under gc-heap->arena->unused, fluctuates a bit, but eventually gets low again. Reopen if necessary.