User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070615 Minefield/3.0a6pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070615 Minefield/3.0a6pre with both 20070615 Minefield and Gran Paradiso a5 I see a huge memory leak with this test. Reproducible: Always Steps to Reproduce: just launch the test and look at memory consumption. I'm using FF in safe mode with default theme, and MS Process Explorer to graph leaks. Actual Results: memory consumption grows indefinitely at a 76MB/minute rate Expected Results: Firefox 220.127.116.11 plays nice with this, freeing memory at regular intervals, and seems also to be "JS kiddie programmers friendly", as if event handlers are not removed at all before removing elements, memory is freed up the same. This test clearly shows an odd behaviour that needs to be fixed.
Created attachment 269194 [details] Analysis from leak-gauge.pl Leak-gauge.pl reports no leakage with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:18.104.22.168pre) Gecko/2007053104 BonEcho/22.214.171.124pre But it does report leakage with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/20070620 Minefield/3.0a6pre ID:2007062013
I can confirm the bug with Gran Paradiso a5 running on Linux, using top to monitor memory consumption. Similary as described on #385329 I notice that closing the testcase page frees few memory, so i'm guessing if or not a page based mark is already put on memory resouces in favour of a garbage collector logic that clears relative marked memory in any case when a corresponding page is closed. I hope not to be out of context here, as i'm guessing top-down and know nothing about garbage collector implemented strategies.
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events
I'm not seeing leaks reported by leak-gauge.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Alexandro, memory leaks are not measured with the "Windows Task Manager" or with "top". That only shows the total amount of memory allocated by the process. Memory that is freed, is still present in the application, and will be used the next time the application needs it. Only a small amount (if any) might be released to the OS again, if that is supported by the memory manager (not all of them do). To make matters worse, the Windows Task Manager shows by default a different number, which might is smaller than the amount of actual process memory. You can not assume that closing a tab will automatically release all the memory back to the OS, and that it would be visible externally. That's why Mozilla developers uses different tools, which really report what's going on. You can observe a part of it (only the memory cache) by looking at about:cache. But keep in mind that there's also a cache that remembers content of pages after they're closed, so that can be quickly reopened. In particular, closing a tab won't have much effect. That's normal !
Seeing persistent memory growth in top is a sign of a bug; that's why I confirmed it.
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #4) > I'm not seeing leaks reported by leak-gauge. You're right. I was running this testcase by loading it in a new tab from the bookmarks toolbar, and closing the tab and then exiting firefox. This is what appears to be causing the leak I saw with leak-gauge.pl here; filed bug 385376.
Created attachment 269365 [details] same testcase + interface to play/pause and change elements/interval
Thanks Jo, in the light of your explaination I tried myself still using the same rude tools and found the following: closing the testcase tab under *Windows* with both FF2 & FF3 shows that more or less the whole memory increment is released immediately. closing the testcase tab under *Linux* with both FF2 & FF3 doesn't show any immediate memory release, then if I launch the testcase again the memory usage doesn't grow anymore until the testcase uses more memory than currently allocated, and If I close the test again FF2/3 progressively release memory as other applications ask resources to the system. Anyway, while FF2 is topping memory usage at about 45/60MB both on windows and linux, FF3 asks the system more and more memory, and in the long run the system hangs. I wasn't able to crash FF3 (good!) when it was eating around 100% of RAM, with systems hanging and disks swapping in my boxes (P3-850, 512MB debian, P4-2.8, 1GB XP), anyway closing FF freezed the system for somewhile (about 1 minute), I guess because then working hard to release such huge piece of ram. FF2 here never goes in such state. If this is a case of different implemented strategies (pardon me for the continued guessing, just trying to help ;-) as ,may be, releasing memory on exit saves some CPU cycles while running, I'd evaluate if the mix of two wins, then, upon a treshold of total memory usage start to progressively release some memory to don't reach the point where the system hangs. Sorry again for the guessing, i haven't budget in knowledge and time to curious around in FF sources, but i'm experiencing on the XUL JS side of the thing and care of it. Thanks
Jonas thinks this has to do with changes in some of the event code from using dbaron's GC participant code to using strong references and relying on the cycle collector collecting the cycles. It would be interesting to know if running this testcase shows the increase in memory if another browser window is used at the same time to load random webpages in it (to trigger cycle collections). Could anyone test and report back?
(In reply to comment #10) > Jonas thinks this has to do with changes in some of the event code from using > dbaron's GC participant code to using strong references and relying on the > cycle collector collecting the cycles. It would be interesting to know if > running this testcase shows the increase in memory if another browser window is > used at the same time to load random webpages in it (to trigger cycle > collections). Could anyone test and report back? Johnny, I can confirm that while browsing other websites continuosly on other tabs or windows memory is released, running the testcase with 20070629 both on Linux and Windows platforms. With this edge case I just can't go away for a coffee break ;-) Seriously, this memleak could unlikely happen, I can just think this could be a problem for an unaware user writing a long blog post or email not saving drafts (on a webapp that doesn't autosave), while having a really badly wroten script running on another tab. What about releasing memory at longer intervals (in respect to FF2) when last triggered memory release becomes too old?
Thanks for the feedback. Resummarising the bug and marking blocker.
Assignee: nobody → jst
Flags: blocking1.9? → blocking1.9+
Summary: huge JS memory leak adding and then removing elements+handlers → Better scheduling of cycle collection/gc
Duping this against bug 373462 as this should be fixed by the work going on in that bug.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 373462
No longer blocks: 383692
You need to log in before you can comment on or make changes to this bug.