Closed Bug 81446 Opened 24 years ago Closed 17 years ago

Reloading leaks memory

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: stephena, Unassigned)

References

(
URL
)

Details

(Keywords: memory-leak, Whiteboard: [ADT3])

Attachments

(14 files, 5 obsolete files)

Purify run - penguin.html [ reloaded twice ]
27.38 KB, text/plain
Details
diffbloatblame's output on Windows 2000
15.92 KB, text/plain
Details
Memory usage after initial display of http://java.sun.com/
113.98 KB, image/jpeg
Details
Memory usage after refresh 10X at http://java.sun.com/
114.23 KB, image/jpeg
Details
Heap analysis results on repeated reloads of java.sun.com
4.75 KB, text/plain
Details
Updated fix which incorporates bzbasky's suggestion
2.63 KB, patch
Details | Diff | Splinter Review
Purify output on S+L+E of java.sun.com
17.87 KB, text/plain
Details
Purify output on S+L+3R+E of java.sun.com
21.51 KB, text/plain
Details
Purify output on S+L+E of www.cnn.com
19.39 KB, text/plain
Details
Purify output on S+L+3R+E of www.cnn.com
20.75 KB, text/plain
Details
Purify output on S+L+E of penguin page (attachment 34969)
17.83 KB, text/plain
Details
Purify output on S+L+3R+E of penguin page (attachment 34969)
17.55 KB, text/plain
Details
Leak fix to nsLocalFile::Clone()
1.13 KB, patch
Details | Diff | Splinter Review
Slightly cheaper version of the above, avoids unnecessary QI and refcounting
1.09 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: mlk
CCing self.
Memory usage is painful, so I'd like to keep an eye on it...
Blocks: 92580
Reporter(tephena@hiwaay.net): Is this still a problem with a more recent build ?

I am seeing this on 2001091103 on windows 2000
No longer blocks: 92580
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.
Assignee: asa → 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
OS: Windows 2000 → All
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.
Assignee: dbaron → cathleen
afaik most of the things with stacks are law's
Component: Browser-General → XP Apps
QA Contact: doronr → cathleen
nisheeth will help investigate :-)
Assignee: cathleen → nisheeth
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.
Status: NEW → ASSIGNED
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
Target Milestone: --- → mozilla0.9.9
Keywords: nsbeta1
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
Target Milestone: mozilla0.9.9 → mozilla1.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!
Target Milestone: mozilla1.0 → mozilla0.9.9
Depends on: 129423
Depends on: 129424
Depends on: 129425
Depends on: 129429
Target Milestone: mozilla0.9.9 → mozilla1.0
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
Attached patch Leak fix (obsolete) — — Splinter Review 
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
Attachment #73336 - Flags: superreview+
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
Attachment #73336 - Flags: review+
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.
Attachment #73336 - Flags: approval+
What bz said, if there's time -- I trust r= and sr= would still apply.

/be
This patch just got checked into the trunk.
Attachment #73336 - Attachment is obsolete: true
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.
Keywords: nsbeta1 → nsbeta1+
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.
Attachment #72109 - Attachment is obsolete: true
Attachment #72110 - Attachment is obsolete: true
Attachment #72111 - Attachment is obsolete: true
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).
Attached patch Leak fix to nsLocalFile::Clone() (obsolete) — — Splinter Review 
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.
Attachment #74037 - Attachment is obsolete: true
ADT3 per ADT triage.
Whiteboard: [ADT3]
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.
Keywords: nsbeta1-
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.
Keywords: nsbeta1+
*** 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.
Target Milestone: mozilla1.0 → ---
bz, wanna roll this fix into the tree?
Assignee: nisheeth → bzbarsky
Status: ASSIGNED → NEW
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 :-)
Priority: -- → P5
Target Milestone: --- → Future
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?
Keywords: nsbeta1- → nsbeta1
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-
Keywords: nsbeta1 → 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.
Blocks: majorbugs, 203448
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....
Assignee: bz-vacation → jag
Priority: P5 → --
QA Contact: cathleennscp → pawyskoczka
Target Milestone: Future → ---
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.
Product: Core → Mozilla Application Suite
(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.
No longer blocks: majorbugs
(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?
Assignee: jag → nobody
Component: XP Apps → General
Product: Mozilla Application Suite → Core
QA Contact: pawyskoczka → general
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: