24540 - Animated Gifs fail (after loop?) and are replaced by image name

Status: VERIFIED DUPLICATE of bug 1031

(Core :: Graphics: ImageLib, defect, P3)

Description

[Michael Baffoni]

When going to several sites with animated Gifs, the looped images would
randomly quit the loop (not all images quit in this manner).  Although
not quite dogfood, and to some a blessing (in the case of hamsterdance.com),
most users will probably be upset with this behavior.

Comment 1

[Eli Goldberg]

QA Assigning to self.

Comment 2

[Sean Richardson]

Loaded the URL with 2000-01-25-09-M14; left the page up; ended up coming
back hours later: Windows NT was complaining that I was out of memory. Closing 
the Mozilla window (normally) released 80+ MB, so it looks like whatever
process is causing the gifs to go away is also leaking memory bigtime.

That's going to be a real problem for pages with many animated gifs that are 
left up for a long time (overnight, half the day, whatever).

But the bigger problem seems to be that Mozilla keeps requesting the images
again and again (judging by modem lights), and as it does, memory usage climbs 
several K per second, so long as the page at the URL above is displayed. 

In effect, it appears that the gif that is already in the image cache is being
ignored, and a reload is being done instead.  Certain that I've seen this
issue before...

The filenames of the gifs are probably appearing because of random load 
failures, nothing more than that.

Comment 3

[Sean Richardson]

[e-mail], could this be a DUP or a cousin of bug 19114,
"Major memory leaking in M11 under W95 OSR2", in conjunction with bug 21036 
"[BETA] Imglib needs to support the necko cache, after it is enabled"?

Comment 4

[Stephen Anderson]

I don't know.  Bug# 19114 used to be big trouble for me.  But, it seemed to be 
triggered by some unknown impetus and it would chew memory when the status bar 
animation was enabled.  Other looping animations (like the throbber) did not 
cause the deterioration noted in that bug.  I don't have any code-level 
knowledge of the problem, but I tend not to think they are related.

Comment 5

[Stephen Anderson]

I was able to reproduce the progressibely failing animations at hamsterdance 
with M13 on Win95.  However, 30 seconds after loading, as the animations 
progressivly failed, mozilla crashed alltogether.  Uping severity to critical 
as does cause nasty crashes.  A talkback log was generated and sent.  Id: 
TB4573877E

Comment 6

[Stephen Anderson]

I went back to an old html webpage I had made that has a single 2-frame 
animated gif on it to try (with M13 W95).  The size of the animation and the 
rate at which is plays tells me that it's not really downloading the GIF for 
every animation.  It's playing too fast and my 56k modem couldn't get it that 
fast.  But there is significant activity on the modem which makes me think it 
is atleast sending a "have you changed" "no I haven't" type conversation 
between each rerun of the animation.

Mozilla does not exhibit any other "bad" behaviour on this simpler page.  To 
me, that gives me a feeling that hamsterdance is probably exposing a failure in 
the content retrieval architecture.  This is surely speculation, but I'd say 
when the content fetch system get's overloaded it tends to crap out and crash.  
I'd say normally the retrieval list is limited to however many items mozilla is 
designed to download simultaneously.  BUT, when you have an animated GIF, after 
it is retrieved the first time, it probably goes on listing more things on the 
page to retrieve, only each animated GIF really hasn't left the retrieval queue 
since it forces a reretrieval request each loop.

All sheer speculation, possibly madness, but it has a sense of plausability to 
it.  On that basis (and the fact that Browser-General bugs don't seem to get 
assigned anymore), I'm redirecting this to the Networking folks.

Comment 7

[Stephen Anderson]

Let's try reassigning this to Networking owner to see if it will get worked 
on.  Don't tell me "nobody" owns networking...

Comment 8

[Eli Goldberg]

baffoni, just FYI, browser-general bugs default to "[e-mail]" so that a 
group of folks like sidr can review them and assign them to the right place. (For 
more information, see http://www.mozilla.org/quality/browser/prescreening.html.)

In the past, Pam Nunn/ImageLib has dealt with bugs like this, so I'm assigning it 
to her (and QA assigning back to me.) 

Comment 9

[Sean Richardson]

Eli, Pam, this bug looks like a bunch of issues in one. I'm inclined to think
that the repeated-request-of-animated-gif problem, bug 21036, together with
the ridiculous number of repetitions of several animated gifs on the 
hampsterdance.com page, are:
(1) exposing a problem with either the image display code or the networking 
    code, that is causing memory burn-through when the images are requested
    again and again.
(2) causing so many reloads or conditional reloads of the animated gifs that
    random chance will cause some of them to fail, causing the primary
    symptom, the replacement of the gifs with their names.
...and once bug 21036 is fixed, problem (1) will be masked or abated,
and problem (2) will no longer be occasioned.

I think it would be better for both problems (1) and (2) to get attention,
rather than figuring that they will become irrelevant once bug 21036 is fixed,
because they may show up in other contexts that are triggered by intentional
refreshing of content (say, a news page on a 20-minute refresh cycle).

I'll write up (2) as a new bug, so this can be about (1). 

Copied one of the gifs from the hampsterdance page to a webserver here,
and sure enough, along with the re-GET every 7 seconds, Mozilla's memory
footprint kept growing, as reported by NT's Task manager, several K per cycle.

Comment 10

[pnunn]

dupe of 1031:
 trace image observer. pn.

We HAVE to fix Hamsterdance!
-p

*** This bug has been marked as a duplicate of 1031 ***

Comment 11

[Eli Goldberg]

Rubber-stamping as verified/duplicate --- with a comment in 1031 to verify this 
bug & other dupes when 1031 is fixed, in case they are separate issues with 
similar symptoms.