Closed
Bug 412065
Opened 17 years ago
Closed 13 years ago
Loading Java API Spec leaks memory
Categories
(Core :: Graphics: ImageLib, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: schapel, Unassigned)
References
()
Details
(Keywords: memory-leak)
Attachments
(3 files)
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.
Flags: blocking1.9?
Reporter | ||
Updated•17 years ago
|
Attachment #296696 -
Attachment description: testcase → testcase (loads API spec every 5 seconds)
Attachment #296696 -
Attachment is obsolete: false
Reporter | ||
Updated•17 years ago
|
Attachment #296697 -
Attachment description: testcase → testcase (loads API spec every 15 seconds)
Reporter | ||
Comment 3•17 years ago
|
||
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.
Reporter | ||
Comment 4•17 years ago
|
||
This is a slightly reduced testcase that reproduces just the GDI object leak. Each time you reload the testcase, it leaks two GDI objects.
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee: nobody → vladimir
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.
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.
Reporter | ||
Comment 7•17 years ago
|
||
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).
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?
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.
Depends on: 415854
Priority: P2 → P3
Updated•17 years ago
|
Priority: P3 → P2
Priority: P2 → P3
Updated•17 years ago
|
Priority: P3 → P2
Updated•17 years ago
|
Flags: tracking1.9+ → blocking1.9+
I believe this was fixed by the checkin for bug 415854.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•17 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Loading Java API Spec leaks memory and GDI objects → Loading Java API Spec leaks memory
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.
Assignee: vladimir → nobody
Status: REOPENED → NEW
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
Reporter | ||
Comment 14•15 years ago
|
||
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.
OS: Windows XP → All
Comment 15•13 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 17 years ago → 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•