From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010516 BuildID: 2001051604 Mozilla's memory footprint progressivly grows when reloading large text-only pages. Reloading http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34969 ten times showed that the memory footprint grew on average 136KB per reload. harishd ran purify on this page and the results are at: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34978 Reproducible: Always Steps to Reproduce: 1. Open a new browser window 2. Load http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34969 3. Open the Task Manager Window and watch Mem Usage Column 4. Reload page comletely about 10-20 times Actual Results: Mem Usage grows on each reload. Expected Results: Mem usage should maybe increase on first reload but then stabilize.

CCing self.

Memory usage is painful, so I'd like to keep an eye on it...

Reporter(tephena@hiwaay.net): Is this still a problem with a more recent build ?

I am seeing this on 2001091103 on windows 2000

I also see this on 2001101803 nightly on winnt.

harishd: Do you know a good component for this bug ? (Browser general will never fix this bug)

->dbaron.

I see an average growth of 1320K on each reload of the supplied attachment on freebsd. you may want to change platform to All.

Ok, -> All

I'm not seeing memory usage increase much, if at all, when reloading http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34969 .

Is this still a problem on Windows? I was testing on Linux.

I can see it with an 1h old CVS build on wind32 if I load the attachment lfrom my HDD.

On Linux, using trace-malloc to look at memory allocated before and after reloading a few times, I only see a 27K increase in memory used. 14K of that is some X stuff that's not our fault. 5K is nsXBLPrototypeHandler objects, which seems like it might be a leak of some sort although it could be something that gets created the first time I use a certain key combination. 4K is frame arena growth. 2K is DEBUG-only nsAutoLock debugging structures. The rest is other miscellaneous things. So I suspect the main problem here is Windows-only. I don't have access to a Windows machine right now. Something that should help show what the problem is, although not necessarily how to fix it (and which I just tried on Linux -- see above) would be to do the following in a build with trace-malloc enabled (which I think is done on windows by pulling mozilla/tools/trace-malloc/ and then building with NS_TRACE_MALLOC=1 -- it may only work in a build that has MOZ_DEBUG=1 as well): 1. start mozilla with command-line options "--trace-malloc=malloc.log" 2. open a second browser window 3. In the first window, load http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34969 4. reload the document once 5. in the second window, load http://www.people.fas.harvard.edu/~dbaron/tmp/trace-malloc.html , and enter the filename "81446-before.log" or something like that (this will then, after a 3 second delay, write a huge logfile that takes close to a gigabyte (yes!) of disk space) 6. reload the document 5 or so times 7. repeat step (5), except with filename "81446-after.log" 8. exit the browser Then, run the perl script in tools/trace-malloc/diffbloatdump.pl with the two logs as arguments, and pipe the output to a file, e.g.: perl c:\...\mozilla\tools\trace-malloc\diffbloatdump.pl 81446-before.log 81446-after.log > 81446-diff.txt and then attach the resulting file 81446-diff.txt to this bug (or, even better, analyze the problem that it shows yourself). Still, before doing that, it would be worth double-checking that memory use is really continuing to increase after the first reload. (Also -- be careful not to start one reload before the previous one has finished -- that would be a different bug -- a load stopped in the middle might be more likely to leak that one that was allowed to finish, and I did all the testing here assuming that those who are seeing this leak are allowing the load to complete.)

->cathleen, since someone needs to investigate this on Windows.

afaik most of the things with stacks are law's

nisheeth will help investigate :-)

I got through all of the steps that dbaron outlined and then crashed mid-way while writing out 81446-after.log. Gotta go now but will repeat the steps tomorrow, generate 81446-diff.txt, and see where it points me.

Tried dbaron's steps and crashed again. Seems like the hash table of allocations used in nsTraceMalloc.c is getting corrupted. Here's the stack trace: allocation_enumerator(PLHashEntry * 0x10358938, int 196425, void * 0x002aa8c8) line 2007 + 3 bytes PL_HashTableEnumerateEntries(PLHashTable * 0x003c99a8, int (PLHashEntry *, int, void *)* 0x10024fc0 allocation_enumerator(PLHashEntry *, int, void *), void * 0x002aa8c8) line 429 + 15 bytes NS_TraceMallocDumpAllocations(const char * 0x1741f5a0) line 2040 + 21 bytes TraceMallocDumpAllocations(JSContext * 0x1655bc78, JSObject * 0x16487260, unsigned int 2, long * 0x1756b030, long * 0x0012f964) line 1378 + 9 bytes js_Invoke(JSContext * 0x1655bc78, unsigned int 2, unsigned int 2) line 832 + 23 bytes js_InternalInvoke(JSContext * 0x1655bc78, JSObject * 0x16487260, long 378780272, unsigned int 0, unsigned int 2, long * 0x16709868, long * 0x0012fad4) line 924 + 20 bytes JS_CallFunctionValue(JSContext * 0x1655bc78, JSObject * 0x16487260, long 378780272, unsigned int 2, long * 0x16709868, long * 0x0012fad4) line 3405 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x165c72c0, void * 0x16487260, void * 0x1693ba70, unsigned int 2, void * 0x16709868, int * 0x0012fb6c, int 0) line 1011 + 33 bytes GlobalWindowImpl::RunTimeout(nsTimeoutImpl * 0x16cb1498) line 3875 + 84 bytes GlobalWindowImpl::TimerCallback(nsITimer * 0x1b8e0030, void * 0x16cb1498) line 4187 nsTimerImpl::Process() line 246 + 17 bytes handleMyEvent(MyEventType * 0x1792d060) line 287 PL_HandleEvent(PLEvent * 0x1792d060) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01b62510) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x000d0034, unsigned int 49670, unsigned int 0, long 28714256) line 1071 + 9 bytes USER32! 77e148dc() USER32! 77e14aa7() USER32! 77e266fd() nsAppShellService::Run(nsAppShellService * const 0x0280d890) line 303 main1(int 2, char * * 0x003c7070, nsISupports * 0x00000000) line 1285 + 32 bytes main(int 2, char * * 0x003c7070) line 1625 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e992a6()

OK, after a few more attempts, I got through all the steps without crashing on my Windows 2000 machine. I'm about to attach 81446-diff.txt to this bug. The steps I followed to generate 81446-diff.txt are exactly what David Baron outlined in his comment above, EXCEPT, instead of reloading the document "5 or so" times in step 6), I reloaded the document 3 times. I found that if I tried to reload more times, I'd crash while writing out 81446-after.log. Now, on to learning from dbaron's spiffy leak docs about interpreting diffbloatblame's output.

Generated from following the steps outlined in dbaron's comment timestamped "2001-12-21 12:16"

18K of increase doesn't look like the massive leak reported, especially when 7K of it is the nsAutoLock debugging code that isn't in release builds. Any ideas why some people see the problem and others don't? Nisheeth -- do you see the Task Manager show increasing memory use? Could it be a resource leak? (Would that show as Mozilla's memory in the task manager?)

Here's the data I get from Task Manager on my machine. I loaded http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34969 and reloaded it multiple times. The comma separated list of numbers is the memory (in KB) reported by Task Manager at the end of successive *reloads*. The leftmost number is the memory measured at the end of the first reload and so on. Each run is a fresh start of my Mozilla debug build from the command line *without* using the trace-malloc parameter. 1st run: 44548, 44464, 44508, 44528, 44548, 47384 2nd run: 44800, 44728, 44720, 44756, 44752, 44712 3rd run: 4388, 44916, 44764, 44792, 44800, 44792, 47828, 44988, 44956, 48468, 45060 The 1st run shows a ~2MB spike on the 6th reload. The 2nd run shows no abnormalities. The 3rd run shows similar spikes on the 7th and 10th reloads but in both cases, memory is reclaimed in the next reload. All in all, I feel like an idiot! When I eyeballed these numbers before running Mozilla in trace-malloc mode, I can swear that I saw a steady increase in memory as I reloaded the page. But, today's more careful examination of memory shows otherwise. Seems like we don't have a problem, even on windows.

Reproduced this problem at http://java.sun.com/. Mozilla memory usage was at 36.8 MB when the page rendered for the first time. After 10 reloads, memory usage was at 40.6 MB. After sitting idle for several minutes, Mozilla memory usage remained between 40 and 41 MB. Using build 2002020103 on Win 2K with 512 MB of RAM.

-> 0.9.9

I used a spacetrace build on windows 2000 to do further analysis on this. I captured the start times of each url load and subsequent reload. The data is given below. task : time : seconds from start ----------------------------------------- start : 10-12-00 : 0 1st start: 10-14-10 : 130 2nd start: 10-15-00 : 180 3rd start: 10-15-30 : 210 4th start: 10-16-00 : 240 5th start: 10-16-30 : 270 6th start: 10-17-00 : 300 7th start: 10-17-30 : 330 8th start: 10-18-00 : 360 9th start: 10-18-30 : 390 10th strt: 10-19-00 : 420 Close : 10-19-30 : 450 I then used the web based interface to spacetrace (http://www.mozilla.org/projects/footprint/spaceTrace.html) and set options to: a) to ignore allocations that were created outside the 170 s to 410 s time interval. b) to ignore allocations that existed solely before or after the 170 s to 410 s time interval. I chose the 170 s to 410 s interval to capture allocations that occurred after the 1st url load through the end of the 9th url load (or the 8th url *reload* because I reloaded the same url after the initial load). In this time interval, two allocation sites dominate memory leakage: a) HTMLAttributesImpl::SetAttributeFor(nsHTMLAttributes.cpp:1202) is responsible for a total of 72016 bytes leaked over 1888 heap objects. b) HTMLStyleSheetImpl::SetAttributeFor(nsHTMLStyleSheet.cpp:1427) is responsible for a total of 45936 bytes leaked over 638 heap objects. I eyeballed the code around these allocation sites to see if the memory leak was obvious but it wasn't. Will have to use the refcount balancer to see what is causing the HTMLAttribute leaks. Also, these leaks don't add up to the ~4MB increase in memory reported in comment 24 by DomIncollingo@austin.rr.com. I have a hunch about where the rest of the memory might be going which I will follow through on next. I think that the Task Manager memory increase might be due to the allocator holding on to freed memory. Will us dp's heapdump tool and heap dump analysis perl script to see if allocator held freed memory increase accounts for the rest of the memory bloat.

see comment 28 for description of how this leak report was generated.

I ran an optimized build of Mozilla with debug symbols and repeatedly reloaded java.sun.com. I ran dp's heap analysis tool after the initial load and each subsequent reload to capture the attached heap data. More analysis soon.

-> 1.0

Thanks a lot to dp for helping me interpret the heapdump results and jband for giving me a braindump on different causes of this monotonic-increase-in-footprint-on-reload behavior. Here's what I plan to do next: 1) Identify the "real" leaks defined as objects or cycles of objects that are left unreferenced on the heap. 2) Plug the leaks identified in 1) 3) Now, hone in on "pseudo" leaks that are objects on lists that grow unbounded as we reload the page but which do get freed on exit. If there is unbounded growth of certain objects, we need to fix it. So, I will see what the behavior is over 50 reloads. If footprint increases monotonically over all those 50 reloads, we have a problem. I'll use spacetrace to identify patterns of object allocation across those reloads to try and figure out which objects are repeatedly being created but not destroyed on each reload. So, to start on step 1), I ran purify on an optmized build on Windows 2000 with MOZ_PROFILE set to 1 and 1) Loaded java.sun.com 2) Reloaded it 10 times 3) Exit Purify reported 551200 bytes of leaked data of which 433126 bytes was leaked from 5 allocation sites. 4 of these sites which accounted for 394206 bytes of leaked data had enough information on the 10 frame call stack to pinpoint blame. I'll next try to figure out where the objects allocated at these 4 call sites are leaked. About to file mem leak bugs as blockers to this bug. Help is appreciated on tracking down those leaks. Thanks!

OK, four mem leak bugs have been filed all of which are blockers to this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=129423 http://bugzilla.mozilla.org/show_bug.cgi?id=129424 http://bugzilla.mozilla.org/show_bug.cgi?id=129425 http://bugzilla.mozilla.org/show_bug.cgi?id=129429 Onwards to fixing these leaks...

Progress, progress. We leak PARAM elements, all 150 or so of them, residing within an APPLET tag on java.sun.com! Lets not even begin to ask why one applet needs to be passed so many parameters! The four leaks above seem to be related. nsHTMLSharedLeafElement (an HTML content object created for PARAM elements) owns nsHTMLAttributeImpl (a class implementing nsIHTMLAttribtues) which in turn owns nsHTMLAttribute (a struct). The hope is that once I plug the leak of PARAM elements all four of the leaks in comment 35 will go way. Lets see what I find! :-)

in comment 36, s/nsHTMLAttributeImpl/nsHTMLAttributesImpl and s/nsHTMLAttribute/HTMLAttribute

OK, this is a patch that fixes our memory leaks on reload for java.sun.com at least. Haven't tried other pages mentioned on this bug yet. I re-ran purify with this patch and checked that we did not leak the 394206 bytes we leaked without this patch from the 4 allocation points detailed in bug 129423, bug 129424, bug 129425, and bug 129429.

The problem was that we assigned an addref'd return value from a function into a COM pointer without wrapping the function call in dont_AddRef(). An extra reference was thus added to the PARAM element by nsObjectFrame::EnsureCachedAttrParamArrays() which caused us to leak the elements and their attributes. Ccing Peter Lubczynski for a review, and Johnny Stenback for a super review to attachment 73336 [details] [diff] [review].

Comment on attachment 73336 [details] [diff] [review] Leak fix Nice catch Nisheeth! sr=jst

That should work... just as a thought, we could eliminate the "sup" temporary entirely by using QueryElementAt or even do_QueryElementAt: nsCOMPtr<nsIDOMElement> param; ourParams->QueryElementAt(idx, NS_GET_IID(nsIDOMElement), getter_AddRefs(param)); or nsCOMPtr<nsIDOMElement> param = do_QueryElementAt(ourParams, idx);

Comment on attachment 73336 [details] [diff] [review] Leak fix r=peterl

Comment on attachment 73336 [details] [diff] [review] Leak fix a=asa (on behalf of drivers) for checkin to the 1.0 trunk. Too late for 0.9.9.

What bz said, if there's time -- I trust r= and sr= would still apply. /be

This patch just got checked into the trunk.

We should be pretty much done with this bug by 3/15. Another bug was fixed which may have fixed this, or at least reduced the amount of memory we leak.

S, L, E, R are explained in the comment right after these attachments.

S, L, E, R are explained in the comment right after these attachments.

S, L, E, R are explained in the comment right after these attachments.

S, L, E, R are explained in the comment right after these attachments.

S, L, E, R are explained in the comment right after these attachments.

S, L, E, R are explained in the comment right after these attachments.

OK, more good news to report. David Bradley found a leak in nsLocalFile::Clone () caused by an accidental checkin of a backed out patch (attachment 67354 [details] [diff] [review] to bug 122892) into nsLocalFileWin.cpp. After reversing the effects of this patch in my local MOZ_PROFILE build, the leaks are as follows. More specifics in the table below. Key: S == Startup, L == Load, E == Exit, R == Reload 1) URL 2) Mem Leak 3) Mem Leak Delta (3 - 2) (S + L + E) (S + L + 3R + E) (3R) ------ ------------- ---------------- ------------- java.sun.com 45694 bytes 49961 bytes 4267 bytes www.cnn.com 48544 bytes 63573 bytes 15029 bytes penguin page 46077 bytes 46065 bytes -8 bytes (Pretty weird!) The url of the "penguin page" is http://bugzilla.mozilla.org/showattachment.cgi? attach_id=34969. The six purify reports used to obtain the six data points in Columns 2 and 3 above are available as attachments 74029 through 74034 on this bug. An interesting point about the above data is that the leak delta for java.sun.com decreased from 50K to ~4K! Yay! I don't understand how the leak delta for the penguin page in the above data is negative. Measurement error? Unlikely because I'm just reporting purify results. This one has me foxed! Next steps: I think leaks across reloads have gone down enough to merit another pass at using dp's heapdump utility to see how mozilla's data usage grows across reloads. If the growth across reloads is much greater than that predicted by the leak deltas above *and* it is unbounded, then we know that it is time to move from plugging leaks (see step 2 of comment 34) to spacetrace based fixup of unbounded object growth (see step 3 of comment 34).

Just to make sure that the leak fix to nsLocalFile::Clone() does not get lost, I'm attaching the patch that fixes it. I'll follow up with the owners, commenters of bug 122892, bug 124497, and related bugs that discuss this patch to make sure that it makes it into Mozilla 1.0. I wanna point out that I did *not* do the work to find this fix. The credit for it goes to dbradley and others who commented and worked on bug 124497.

Second attempt to attach patch. The last patch was unreadable because of broken line wrapping.

ADT3 per ADT triage.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

*** Bug 142221 has been marked as a duplicate of this bug. ***

I just installed Mozilla 1.1beta and it has a massive memory leak when I leave up my webcam page (which reloads every couple of seconds). Overnight it used up about 300MB. I didn't want to file a duplicate bug but noticed that this bug is for "text only" pages. Is this the correct bug for my problem or should I file a separate one? To see the problem I'm having, visit http://www.ncc.com/humans/srainwater/ then click on my photo to load the web cam window. Run top and you should see it leaking memory within a minute or two...

1.0 is gone. I suspect Nisheeth is too busy with something else, so we should find a new owner for this.

bz, wanna roll this fix into the tree?

The leak fix to nsLocalFile::Clone() was checked in when bug 124497 was fixed. That is why I didn't check in my patch or the modifications made to it by jst. This bug is still open because the general "reloading leaks memory" problem still needs more work.

So... do we have any clues at all as to _what_ is leaking? I'll have no time to do dig into things like this till at least mid-september, so I'm not a good person to assign this to...

Nobody else has the time either, so it doesn't really matter where this sits :-)

The massive memory leak introduced in the 1.1alpha/beta versions made it through to the 1.1 release alive and well. On my webcam page (see comment #61 for URL), which reloads every couple of seconds, Mozilla v1.1 bloated up and died after about 12 hours, taking X Windows with it. I had to telnet into my workstation and reboot it to get things working again. I've gone back to the older, non-leaky 1.0 version until this gets fixed. I can leave the older mozilla version up with my webcam showing for weeks at a time with no noticeable memory leakage. Shouldn't a bug that causes not only Mozilla but X to crash be bumped up to a high enough priority that it blocks a release from happening? Apparently not, but this might be something to consider for the future...

Just tried out 1.2beta and there seems to have been a slight improvement on this bug. Prior versions would use all available memory and crash X Windows within about 12 hours on pages that reloaded automatically. 1.2beta made it nearly twice that before crashing. Any chance of this bug being closed before the 1.2 release?

Are people still seeing this? With a current linux build, memory usage on http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34969 seems to stabilize after about 3 reloads (thereafter it will sometimes go up or down 4k per reload or not change at all). If I can't reproduce it, I can't fix it....

seems to be wfm on win2k

I just noticed that Mozilla used 110 mb of ram after 4 hours of use, try http://www.aftonbladet.se and reload the page several times, sometimes the increase of memory is 0.5-1 mb/reload. Blocking images help, but still mozilla leaks memory for every reload.

I can confirm this is still around in WinXP 20030421. Loading www.aftonbladet.se boosts mem use from 19,864 MB to 25,180. Hitting back reclaims only ~2MB (23,660), and going back to aftonbladet creeps up to 27,200 MB.

Happens here as well, on Redhat 9 and 1.4beta. Mozilla leaks roughly 1M per reload of aftonbladet.se, and allocates some 5-10 pixmaps in the X server per reload that are never freed.

adt: nsbeta1-

*** Bug 215746 has been marked as a duplicate of this bug. ***

I don't know if this is the same issue or not, but it's the nearest I could find. While writing a PHP script I accidentally created an infinite loop after asking for authentication (auth-type: basic) that spewed all sorts of debugging info to the browser. Something on the order of 500MBs worth. I thought Mozilla had locked up until I noticed my swap usage growing out of control. I couldn't hit stop, but I restarted apache to close the connection. Could this be a problem in the cache management? I don't recall if I hit reload or back and then forward, but the page should have been removed from cache when it was revisited, and this did not happen. Build: mozilla stable [1.4] from Debian unstable (don't have access to the build number from here, sorry); Linux, obviously.

Well, because the Mozilla and the Mozilla Firebird eat too much memory, I searched the bug list. 71306 may be related to this bug. I think that this problem should be solved for achieving the goal of the Firebird, a slim and fast browser. I compared the memory usuage pattern of the Mozilla Suite (1.5) and the Mozilla Firebird (0.7+). The memory usage patterns seem to be identical. I don't think this bug is new. I noticed this problem for long time.

I have no idea if reloading is seperated with loading because I didn't read the source code. However, I think that loading itself causes memory leakage. (Probably.... the reloading calls loading function with same URL, right? :) )

I have no plans to ever work on this, so punting to default owner....

I could not reproduce this bug with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 and the penguin url. Also I could not reproduce this with http://www.heise.de and disabled images. But the memory allocation grow with approx. 700 kbyte for each reload if I enable image load (like comment 71). Some facts that I observed: Classes with increasing number of objects are gfxImageFrame, imgContainerGIF, imgRequest, nsCacheEntry, nsImageWin, nsStandardURL, nsStorageStream, nsVoidArray. These classes are also leaking if cache memory is fully used. (about:cache shows nearly constant values for 'Storage in use,' the values for 'Number of entries' are always increasing.) These classes are not leaking if I end mozilla, so it seems that the references are stored and are released when mozilla ends, but not when mozilla (re)loads a website. My computer is behind a proxy. If have no leaks if I save the page and reload it from the harddisk. btw: nsVoidArray also increases if I reload about:bloat

Some images URLs on http://www.heise.de are dynamical created and shows the same image. The different URLs gives different cache keys. So, each reload will fills the memory cache more and more. I thought my cache was full when making the tests for comment 80, but I was wrong. So, the behaviour I described in comment 80 is no bug.

Still seeing this under Camino nightly build 2004021608, Mac OS 10.3.2. Followed reproduction steps as described in Comment #1. The Mac OS X Activity Monitor shows Camino guzzles memory exactly as described in Comment #1.

I just wanted to point out that I saw something vaguely similar to <a href='http://bugzilla.mozilla.org/show_bug.cgi?id=81446#c76'>comment 76</a>. I was using Mozilla 1.7b under Linux and I tried to load a very simple XUL file on a server that had a .htaccess file that required basic authentication. When the user/password dialog popped up, mozilla had grown from around 20MB to 180MB (this is before the XUL file had even been retrieved, so it wasn't a coding issue). If I removed the .htaccess file the problem went away, and when I restored it the problem returned. In contrast to comment 76, I saw no sign of looping (Apache logs did not show a flood of hits). I exited the browser and reloaded the page, and it consistently ate 180MB every time. I tried going into preferences and clearing the cache, but it did not help. I tried loading the same page with Mozilla 1.6 and Firefox 0.8, and there was no problem. I finally quit out of KDE and logged back in. The problem was then gone. I've run into similar memory consumption before with Firefox 0.8.

Yikes! Darin, any thoughts on the last comment? Any known leaks in our http auth code, or any of the related UI that you know about?

The leak that I mentioned in comment 83 resurfaced today. I quit and restarted Mozilla 1.7b (Linux) several times and it ate 180MB every time I tried to access any page with basic authentication. I then tried Firefox 0.8 and Mozilla 1.6 and had no problems. I then tried Mozilla 1.7b again and the problem was gone (without logging out this time). Is there anything I can do to collect more useful information if I see it again?

This bug is about leaking while reloading text-only documents, not about leaks related to basic auth.

(In reply to comment #86) > This bug is about leaking while reloading text-only documents, not about leaks > related to basic auth. Is there separate bug for this case then? Is it still valid for Firefox 1.0 and Mozilla 1.7.3? I'll try to reproduce it later at home.

(In reply to comment #77) > Well, because the Mozilla and the Mozilla Firebird eat too much memory, I > searched the bug list. 71306 may be related to this bug. unrelated > I think that this problem should be solved for achieving the goal of the > Firebird, a slim and fast browser. not so far. with URL still happens in newly released FF 1.5 winXP, perhaps not as bad as reported previously in this bug. After first couple accesses the testcase consumes 0-500k per reload, bug most times near zero.

This bug looks that it's better to be nominated to Bug 320915... > 320915 : 1.8 memory leak campaign All problem reporters, see Bug 320915 Comment #28, and check reports of "leak-gauge" tool first with newest trunk nightly/new profile. Many memory leak problems(both by mozilla and by extentions) are already found by the tool and reported to bugzilla.

Does reloading the testcase still leak things on trunk?

Jesse in comment #90 > Does reloading the testcase still leak things on trunk? didn't run leak guage extension against attachment 34969 [details] (doesn't run on trunk), just windows task manager. still a problem as judged by first, second and third reload - memory usage goes up 400-800k per reload. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100304 Minefield/3.0a9pre latest doesn't seem Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007110805 Minefield/3.0b2pre not finding anything related with simple search. can't tell if bug 97815 is related.

Yes, reloading the page does make memory go up. It also goes down if you keep reloading. Even after reloading attachment 34969 [details] hundreds of times using Firefox 3 beta 2 rc 1 on Windows XP, memory use kept going back down below 90 MB. If there were a memory leak, memory use would keep increasing so that eventually memory use would not be able to go below 90 MB. leak-gauge.pl reports 0 leaks. Does anyone have a page that causes memory use to increase without limit when it is repeatedly reloaded in Firefox 3? Or a page that causes leak-gauge.pl to report a leak when reloaded in Firefox 3?

The iGoogle home page (logged in or not) increases memory use for about 10 reloads or so, but beyond that seems to have no effect, or the memory even starts going down by tiny amounts. Each reload seems to use about 600-1200kB more RAM before the odd upper limit is reached. I ran leak-gauge.pl, but it returned 0 leaks. This is using the Firefox 3 Beta 2 release, Windows Vista (ugh), with Adblock Plus and Adblock Plus: Element Hiding Helper both installed but disabled. I suspect that it may be some sort of cache keeping previous versions of the page due to the strange cap it hits at about 10 reloads, so I tried setting browser.sessionhistory.max_total_viewers to 0 (if I'm not mistaken, this controls the back/forward cache), but the leak remained.

If reloading a page causes a memory leak, memory use will increase memory without limit if you continue to reload the page. Can you find a page that causes that effect, or one that a memory leak detector says causes a leak when you reload it? If not, this bug seems to be WFM.