From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.0.3 (X11; Linux i686; U;) Gecko/20020211 BuildID: [Mozilla] Mozilla 0.9.8 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 Segmentation fault Reproducible: Always Steps to Reproduce: 1.load url 2.wait until almost finished 3.see it crash :) Actual Results: Segmentation fault Expected Results: rendering the site :-)

wfm using build 2002021503 on Win2k.

wfm with a 1h old win2 CVS build

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020214 I crashed. talkback ID TB2998045Q

I am unable to reproduce the crash loading the page locally. 5% of the time, it hangs during load, and 90% of the time, it hangs if I reload, and the rest of the time, it hangs if I reload again. I reduced the hang problem to an animated gif on the right side (the second, larger one). The crash on the URL appears to occur while it is loading the animated gif that causes the hang. Also, with a debug build, I get a crash with just the gif, but it still only occurs on reload, so the stack trace is completely different. The offending image is (the URL in the page is a redirection script): http://ad.de.doubleclick.net/viewad/353861-teccd_120x1201.gif

Related to bug 94336?

running mozilla --debug on 2002021206 produces a better backtrace.. #0 0x40563368 in chunk_free () from /lib/i686/libc.so.6 #1 0x40564a0f in free () from /lib/i686/libc.so.6 #2 0x401d432a in PR_Free () from /usr/local/mozilla/libnspr4.so #3 0x4012a4e0 in PL_HashTableFinalize () from /usr/local/mozilla/libxpcom.so #4 0x4012a3d5 in PL_HashTableFinalize () from /usr/local/mozilla/libxpcom.so etc.

Daniel: it's possible, but bug #94336 should always crash instead of hang. the fix for that bug should get in soon, so we will know for sure after that. alge: I would classify that as a "different" rather than "better" stack trace. You seem to be crashing somewhere completely different (at least through your #5).

Andrew: True, but a segfault right after a Free() is much more likely the reason for the crash than XEmptyRegion(), I think. I'm not c++ wizard so I might be horribly wrong, of course (= Btw, it crashes for me if I load the page then press the *back* button. Maybe something is wrong with freeing the memory for this gif, that would explain the reload thing to, right?

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

I crashed too. (Not exactly the URL above but surfing http://www.tecchannel.de/) Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020216 TB3015246W

I crashed too. (Not exactly the URL above but surfing http://www.tecchannel.de/) Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020216 TB3015246W

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

Reporter of bug 126030 tracked problem down to these animated gifs found on techchannel: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=69964 (immediate crash) http://bugzilla.mozilla.org/showattachment.cgi?attach_id=69965 (crash on exit after viewing) So this should be at least --> ImgLib

Crash can be reproduced with Mozilla 0.9.8 and nightly build 2002021621.

->imagelib

Freezes browser on linux build 2002021810, marking new (FYI, no crash on XP or OS X)

taking it to self

Bug 123611 is also a dup. of thisone.. The problem in 123611 isn't the link on symlink.ch.. the problem is only the tecchannel page.. (Could someone with enough rights in bugzilla add 123611 as a dup of this? thx!)

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

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

this is a dupe of bug 94336. I hacked 94336's patch to work with current CVS, and this gif also worked. The red text sliding along the bottom is partially off screen as it slides in.

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