Animated gif leaks memory




19 years ago
13 years ago


(Reporter: waqar, Assigned: gagan)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+] Looks okay, but seeking verification w/Purify., URL)


(2 attachments)



19 years ago
Some images on the above page leak memory.

Comment 1

19 years ago
Created attachment 6085 [details]
One if the animated gif that leaks memory


19 years ago
Keywords: beta1


19 years ago
Blocks: 29862

Comment 2

19 years ago
I know you folks were working on this, and partial fixes.  The meg/minute leak 
rate is Very Bad. I think you folks have something that will bring it down to a 
tolerable level.  I'll PDT+ the fix (patch? hack?) that gets us out of real 
trouble, but please add info to indicate how bad the leak is if you want to go 
for further corrections.
On 3/7, we'll probably have to give up on this (unless we're still in the 
MB/minute rate :-( ).
Whiteboard: [PDT+] w/b minus on 3/7

Comment 3

19 years ago
We leak about a meg a minute sitting on as of last 
night. I filed a bug on that and it should be marked as a dup of this, but I 
can't find it in bugzilla at the moment (probably due to bugzilla being a bit 
messed up).

Comment 4

19 years ago
I was out Friday so I am seeing this for the first time now.
Do you happen to know if this is a new leak? A week ago, glowcode
gave us a ok on animateds.

I'll start looking at this with purify. If anyone else has a good
or better tool to look at leaks, I'd appreciate knowing about it/and/or

Target Milestone: M14

Comment 5

19 years ago is a purify log for 

A really easy way to reproduce this is to just go and visit (what I did for that log) and then just sit there and 
watch the memory usage grow.

Comment 6

19 years ago
Same thing happens if you go to the page. Just visit the page and 

let it sit there and watch the memory usage go up, about a .5MB/s.

Comment 7

19 years ago
Thanks for the log, Bruce.

Comment 8

19 years ago
*** Bug 30629 has been marked as a duplicate of this bug. ***

Comment 9

19 years ago
from my NT purify it looks like the leaks are in memcache code.
Also I get an assert that there is "a failure to shut down memcache cleanly".
in mozilla/netwerk/cache/memcache/nsMemCache.cpp.

Its a start.

Comment 10

19 years ago
If this is what is also in my log, it looked to me like memcache stuff was 
leaking, at least in part, due to the nsHTTPChannel being leaked in its 

MLK: 163800 bytes leaked in 975 blocks
  * This memory was allocated from:
        malloc         [rtlib.o]
        __bUiLtIn_nEw  []
        __builtin_new  [rtlib.o]
char*,nsIURI*,nsILoadGroup*,nsIInterfaceRequestor*,unsigned int,nsIURI*,unsigned 
int,unsigned int,nsIChannel**) [nsHTTPHandler.cpp:263]
char*,nsIURI*,nsILoadGroup*,nsIInterfaceRequestor*,unsigned int,nsIURI*,unsigned 
int,unsigned int,nsIChannel**) [nsIOService.cpp:241]
int,unsigned int,unsigned int) [nsNetUtil.h:79]
        il_image_complete(il_container_struct*) [if.cpp:1551]
        ImgDCallbk::ImgDCBHaveImageAll() [if.cpp:185]
        process_buffered_gif_input_data(gif_struct*) [gif.cpp:692]
        gif_delay_time_callback(void*) [gif.cpp:725]
        timer_callback(nsITimer*,void*) [nsImageSystemServices.cpp:70]
        nsTimerGtk::FireTimeout() [nsTimerGtk.cpp:58]
        nsTimerExpired [nsTimerGtk.cpp:175]
        g_timeout_dispatch [gmain.c:1147]
        g_main_dispatch [gmain.c:647]
        g_main_iterate [gmain.c:854]
        g_main_run     [gmain.c:912]
        gtk_main       [gtkmain.c:475]
        nsAppShell::Run() [nsAppShell.cpp:304]
        nsAppShellService::Run() [nsAppShellService.cpp:392]
        main1(int,char**,nsISplashScreen*) [nsAppRunner.cpp:769]
        main           [nsAppRunner.cpp:889]
        _start         [crt1.o]
  * Block of 168 bytes (975 times); last block at 0x292c508

Why are we leaking 975 channels?  Why are we even creating that many?  
Everything that I see coming from the memcache appears to originate with these 
nsHTTPChannel objects.

Comment 11

19 years ago
Although this is a significant leak.... I have to hope we can survice a beta1.
The 3/7 "give up" date.
Marking PDT- for beta1
PDT+ for beta2
Whiteboard: [PDT+] w/b minus on 3/7 → [PDT-] plus for beta2

Comment 12

19 years ago
I give up.

Comment 13

19 years ago
I really hope the PDT will reconsider this one.  As jar said on 3/5/00, a
"meg/minute leak is Very Bad".  So bad, in fact, that I will not be able to use
a netscape beta product that leaks like this.  I think basically any solution is
better than this leak, even Bruce's idea of disabling animated gifs.  Realize
that this affects very badly.  Someone on the PDT should just
let their browser sit on for an hour or so and see what happens
to their performance.  It's not pretty.

To reiterate:  I am convinced that you cannot survive a beta with this bug.
More concretely, I will not use the netscape commericial beta if it has this
problem.  I've tried to just ignore it, but it degrades performance too much to
allow me to do so.

I'm now quitting this M15 build and starting up my nice dependable m14 build.
Thanks for reconsidering.

Comment 14

19 years ago
Maybe this has something to do with using the url string vs. uri object in the 
memcache, as mentioned in bug 29853, since the image is refetched every cycle.

Comment 15

19 years ago
Gagan is looking at channel code & asked me to hold off
for a day.  Any news Gagan?

Comment 16

19 years ago
I would dearly love to have a fix, or a work-around to stop this leak.  If folks
can provide a safe work-around (in the extreme, I agree, disabling animated gifs
would be considered), then remove the PDT-, and re-nominate.  I think the leak
has been reduced *greatly* (and is no longer as bad as "megs/minute").
If there is new info (work-around? fix?) or evidence that this is worse than I'm
understanding, please give details, and renominate (re: remove "PDT-" to attract
attention of the PDT).
We have to ship... dates are real... so we'll have to take pain if we have
nothing to help with this in short order :-( :-(.

Comment 17

19 years ago
Please reconsider this for beta1! I was sitting on, walked away
for 10 minutes, and came back to find mozilla with a 200 meg memory partition
(last night's build, 3/8/2000 midnight)!

This is *NOT* acceptable for beta1, and I don't think it has gotten better. It
will bring lesser machine to their knees before even a few pages have been
rendered. We can't afford that kind of severe, obvious bug...

Whiteboard: [PDT-] plus for beta2 → plus for beta2

Comment 18

19 years ago
I will be checking in the fix for the 29862 bug, it has been approved. This will 
reduce the memory leak quite a bit.

Comment 19

19 years ago
The JS changes that waqar is landing *should* take care of the large
(meg/minute) leak that I mentioned earlier.  Apparently JS was holding refs, and
leaking memory, for animated gifs that were no longer visible.
I expect the leak amounts to be very "tolerable."  If my information is in
error, please add info to this bug (after the landing from waqar has done its

Comment 20

19 years ago
thanks for the good news...
Should this bug be reassigned to you, or should
I hold it for any other animated image related leaks?


Comment 21

19 years ago
Putting on PDT- radar for beta1. 
Keywords: beta2
Whiteboard: plus for beta2 → [PDT-]plus for beta2

Comment 22

19 years ago
Pam, you should hold this bug for other animated gifs leak, 29862 does not fix 
the animated leaks, it fixes the javascript realted memory leaks.

Comment 23

19 years ago
You mean like the animated gifs leaks like the one
due to the nsHTTPChannel...... ;-)

Comment 24

19 years ago
I think so, if just load an animated gif, the one I added here, you will see 
memory being leaked. has lots of animated gifs, so the problem was 

Comment 25

19 years ago
Leaks _anywhere_ are more obvious with an animated gif page.

Comment 26

19 years ago
gagan indicated to me that he had a fix for some of this (the leaking 
nsHTTPChannel objects).  However, that was somewhere around 4-5am, so it'll be a 
bit longer before he's awake.

Comment 27

19 years ago
I am awake now, and I have a fix... essentially the problem was that we were
addreffing an nsHTTPChannel (quite unnecessarily) for the cacheNetData objects.
I think this was a left over of the changes rpotts was making. Anyhow, I cleaned
that up and the nsHTTPChannel leak per animation cycle is now gone! I will check
it in soon... Bruce will have to run his magic to verify this and identify other

Comment 28

19 years ago
Created attachment 6337 [details] [diff] [review]
diffs for fixing the mem leak...

Comment 29

19 years ago
diffs attached as above... need someone to r/a it...

Comment 30

19 years ago
thanks for the news, Bruce.

Comment 31

19 years ago
this should be plus for beta1! cc'ing jevering per his suggestion...

Comment 32

19 years ago
BTW the diffs are from mozilla/netwerk directory and so they missed out on the
diff for imap-

Index: nsImapProtocol.cpp
RCS file: /cvsroot/mozilla/mailnews/imap/src/nsImapProtocol.cpp,v
retrieving revision 1.234
diff -r1.234 nsImapProtocol.cpp
<     rv = cacheEntry->NewChannel(m_loadGroup, this,
>     rv = cacheEntry->NewChannel(m_loadGroup, getter_AddRefs(cacheChannel));


19 years ago
Whiteboard: [PDT-]plus for beta2

Comment 33

19 years ago
PDT, reconsider this.  I think this *needs* to be in the beta.  It is leaking
like 2 meg every 10 seconds on animated images.  This is a HUGE leak and the fix
is simple.

Comment 34

19 years ago
*** Bug 31371 has been marked as a duplicate of this bug. ***

Comment 35

19 years ago
taking over... to stomp on it with more force... other verifyable links which
cause disaster without this fix are and 
Assignee: pnunn → gagan
Sorry about the dup, don't know how I missed it.

The fix looks good to me.

Comment 37

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 38

19 years ago
I saw gagan had a fix in hand (with several days of testing on all three
platforms)... and I even approved it for checkin (subject to chofmann's metering
etc.)  What happened to the fix? When will it land???
Whiteboard: [PDT+] → [PDT+] fix in hand (tested, reviewed, and approved)

Comment 39

19 years ago
the branch wasn't ready till when I left on Friday. I will check it in today as
soon as the tree opens (since I need to do the same with the tip)

Comment 40

19 years ago
checked in on the branch, still waiting for tree open for tip...

Comment 41

19 years ago
fix checked in on tip as well... marking fixed. 
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 42

19 years ago
[Holding verification until tomorrow AM. Not currently alert enough to verify
this well.]

Comment 43

19 years ago
Using this morning's Win32 build, I'm seeing an increase in application memory
usage of 4 megabytes after leaving the page running for 20
minutes unattended.

However, I'm not sure if this increase in memory usage is related to the
animated GIF or not, since I don't see a regular memory increase on a minute by
minute basis in the 7 minutes since I came back., might you be open to giving this a Purify check on Really
Short Notice?
Whiteboard: [PDT+] fix in hand (tested, reviewed, and approved) → [PDT+] Looks okay, but seeking verification w/Purify.

Comment 44

19 years ago
I fear asking this, but do you have purify Eli?  I know that suresh in mail/news 
QA does.

Comment 45

19 years ago
Sorry, no such fancy tools in browser QA. ;)

Comment 46

19 years ago
Order some?  I'll continue this offline though I think.

Comment 47

19 years ago
Using this morning's commercial beta-branch builds:
	* After about 1.5 hours displaying
Netscape's memory partition increases by 200K
	* After about 30 minutes displaying the same page on Mac OS, the memory 
partition remains unchanged (rounded off at hundreds of kilobytes)
	* After about 10 minutes on Linux (assuming VSZ in ps actually means memory)

Thus, verifying as fixed. Anyone with tools to do a more detailed check on why 
the Win32 partition is increasing slightly is welcome to.


19 years ago
Keywords: nsbeta2

Comment 48

13 years ago
The problem is still in the very last firefox release (but not in mozilla
suite) try
You need to log in before you can comment on or make changes to this bug.