crash stack: il_delete_container

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
ImageLib
P3
blocker
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: david mansfield, Assigned: Stuart Parmenter)

Tracking

({crash})

Trunk
mozilla0.9.1
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: patch attached, URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Visiting this page from Linux crashes mozilla.  I have tried about 4 of the last
10 builds (based on good feedback on mozillazine.org/build_comments).  Most of
the time mozilla exits with no messages.  Sometimes it hangs completely.

Note, it takes about 15 seconds to crash - the progress bar goes to about 90
percent, all seems well.  Time goes by (5 seconds or so usually), then
everything freezes (animated gifs) and then a few seconds later - boom, its gone.

Build id is 2000113008.  System is updated redhat 6.2.

Updated

17 years ago
Assignee: asa → pnunn
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston

Comment 1

17 years ago
crash at:

http://lxr.mozilla.org/seamonkey/source/modules/libimg/src/ilclient.cpp#647

stack trace win98 CVS:


il_delete_container(il_container_struct * 0x02467c60) line 647 + 42 bytes
IL_NetRequestDone(il_container_struct * 0x02467c60, ilIURL * 0x02467e40, int 0)
line 1179 + 9 bytes
NetReaderImpl::NetRequestDone(NetReaderImpl * const 0x02465db0, ilIURL *
0x02467e40, int 0) line 139 + 20 bytes
ImageConsumer::OnStopRequest(ImageConsumer * const 0x02465e80, nsIChannel *
0x024644e0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00519bc0 gCommonEmptyBuffer) line 551
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x02464d60,
nsIChannel * 0x024644e0, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00519bc0 gCommonEmptyBuffer) line 277
nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x02464f80,
nsIChannel * 0x024644e0, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00519bc0 gCommonEmptyBuffer) line 1159 + 42 bytes
InterceptStreamListener::OnStopRequest(InterceptStreamListener * const
0x02486050, nsIChannel * 0x024644e0, nsISupports * 0x00000000, unsigned int 0,
const unsigned short * 0x00519bc0 gCommonEmptyBuffer) line 1212
nsHTTPChunkConv::OnStopRequest(nsHTTPChunkConv * const 0x00b51bd8, nsIChannel *
0x024644e0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00519bc0 gCommonEmptyBuffer) line 109
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x00b51bd8, unsigned int 0,
const unsigned short * 0x00519bc0 gCommonEmptyBuffer) line 1923 + 42 bytes
nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x024837a0,
nsIChannel * 0x031e2584, nsISupports * 0x024644e0, unsigned int 0, const
unsigned short * 0x00519bc0 gCommonEmptyBuffer) line 730
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x02481f60) line
300 + 46 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02481f70) line 92 + 12 bytes
PL_HandleEvent(PLEvent * 0x02481f70) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x014234f0) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00000d04, unsigned int 55188, unsigned int 0,
long 21116144) line 1054 + 9 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()
008c8ca2()
This crashes me on build 2000113004, Windows NT.  Setting OS/platform to ALL,
and confirming bug (it may be a DUP though).  Adding keyword crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
OS: Linux → All

Comment 4

17 years ago
Also crashes on Mac OS 8.6, most recent build (had no ID I could locate).

Updated

17 years ago
Status: NEW → ASSIGNED

Updated

17 years ago
Summary: this URL crashes mozilla with no messages → stack: il_delete_container

Updated

17 years ago
Summary: stack: il_delete_container → crash stack: il_delete_container

Comment 5

17 years ago
*** Bug 61654 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
*** Bug 61591 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
Bug 61654, which was just marked a dupe of this, has
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=20139 which is a test
case.

Comment 8

17 years ago
*** Bug 60460 has been marked as a duplicate of this bug. ***

Comment 9

17 years ago
thanks, bb.
The problem is not in the image itself. We can display it fine....
assuming you can say we display a 1x1 transparent gif image. ;)

The image is used to do user tracking for marketing folk. You can't see
the image and your browser has to connect to a different server to access
this invisible image. The server can then store all sorts of info from
the connection.

My current theory is the problem is related to timing.
-p

Comment 10

17 years ago
I don't know if it displays a 1x1 transparent gif - clicking on that link just
crashes for me (at least it did last time I looked). Its only the image in that
case, so theres no other server involved. Its not the tracking part either - the
bugzilla attachment doesn't send that off, I presume. The assertion beforehand
is probably also a Bad Thing.

Comment 11

17 years ago
ah ha!
I'm a bucket head. You are right. This gif doesn't have
a terminator!. 
and if I trace the decoding of the idiot gif, it does in fact
hit the error code.

...

Comment 12

17 years ago
And we hit the end of the net request before we
hit the error in the gif decoder.
ok.
we're on terra firma. I have a fix I can test tuesday.
-p

Comment 13

17 years ago
If anyone wants to try out the patch before tuesday, I'll attach it to
the bug.

Comment 14

17 years ago
Created attachment 21225 [details] [diff] [review]
patch for bug#61756

Updated

17 years ago
Whiteboard: patch attached

Comment 15

17 years ago
Yep, this fixes it, and a random sampling of the dupe bugs don't crash either (I
didn't test that those crashed before the patch though). Linux + current CVS + patch

Thanks!

Comment 16

17 years ago
when this patch will go in the trunk? these crashes are really irritating...

Comment 17

17 years ago
*** Bug 62973 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
I'm still crashing, but it is in unrelated code in views during layout. I'm 
updating my build again in hopes that I can verify this...

Comment 19

17 years ago
I was working with a tree about 5 days old.
I'm updating it to see if I can duplicate the
crash in views...
-p

Comment 20

17 years ago
The crash can be duped on multiple machines. I filed a bug.

Comment 21

17 years ago
This patch looks good, no more crashing for me (on all the tests except for
praystation.com which is the other, different bug)

Comment 22

17 years ago
super. Guess you get to start the moz review process now.
thnx.
CU later. much later.
-p

Comment 23

17 years ago
*** Bug 61169 has been marked as a duplicate of this bug. ***

Comment 24

17 years ago
Is the patch being reviewed?  The fix fixes 61169 and we want it to be
in the trunk.  Thanks.

Comment 25

17 years ago
To expand on Margaret's last comment. We (Sun) are trying to get Netscape 6
distributed internally here at Sun. In order to do that, the IT-OPS support
people have requested that certain "show-stopper" bugs be fixed. This is
one of them (actually 61169, but it's the same problem). We will be building
this new internal release from the OEM branch. Checkin criteria for the OEM
branch is that the fix must have already been applied to the Mozilla trunk.
We are trying to set a code freeze date for our internal release of next 
Tuesday (1/16/01), so there is a certain degree of urgency with this.

Is there any chance that this fix can be r='ed, a='ed and checked into 
the trunk this week please?

Thanks.

Comment 26

17 years ago
*** Bug 65195 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
CC'ing tor@cs.brown.edu for sr=. tor, who should r= this?

Comment 28

17 years ago
Probably saari.

Comment 29

17 years ago
*** Bug 64015 has been marked as a duplicate of this bug. ***

Comment 30

17 years ago
*** Bug 65077 has been marked as a duplicate of this bug. ***

Comment 31

17 years ago
argh... the one-line fix is in hand for almost month now, and still not in the
tree! and its for _blocker_! can we say something is wrong with mozilla
reviewing process?

Comment 32

17 years ago
Sorry, my bad for dropping this on the floor. r=saari (tested a while ago)

Comment 33

17 years ago
saari: actually reviewed, and not just tested?

Updated

17 years ago
Keywords: patch
Hardware: PC → All

Comment 34

17 years ago
See also bug 65821, which may be related.

Comment 35

17 years ago
*** Bug 65821 has been marked as a duplicate of this bug. ***
Blocks: 66164
I've got a similar stack trace at:

	http://bugzilla.mozilla.org/showattachment.cgi?attach_id=23255

as part of bug 66164.

I'll try the attached patch.
No longer blocks: 66164
Blocks: 66164
With a recent nightly build (1/22/2001), the patch from this bug, and the patch
from bug 61386, I'm no longer able to reproduce this bug following the procedure
in bug 66164.
What's the holdup on sr= for this?  It's a 5-line patch that looks obviously
correct.  It's the only thing stopping me from doing final testing and
(hopefully) closing bug 66164.

Thanks!

Comment 39

17 years ago
*** Bug 65920 has been marked as a duplicate of this bug. ***

Comment 40

17 years ago
*** Bug 66893 has been marked as a duplicate of this bug. ***

Comment 41

17 years ago
*** Bug 66893 has been marked as a duplicate of this bug. ***

Comment 42

17 years ago
*** Bug 66893 has been marked as a duplicate of this bug. ***

Comment 43

17 years ago
i vote for mostfreq...

Comment 44

17 years ago
You're right, 11 direct duplicates so far and lots of indirect ones ...
adding mostfreq keyword.
Keywords: mostfreq

Comment 45

17 years ago
Adding Review Keyword
Keywords: review

Comment 46

17 years ago
*** Bug 67170 has been marked as a duplicate of this bug. ***
sr=shaver -- crashing on damned debug code is lame, and this is hurting lots of
people.  Get it in the tree!

Comment 48

17 years ago
Adding nsbeta1 keyword.  Can we get this checked in soon?

Adding Gagan to the CC in case Pam's not available to check in.
Keywords: nsbeta1

Comment 49

17 years ago
doh! how embarassing!... I'll check this in tonight (though I'll strip off 
debug_kipp stuff)
Assignee: pnunn → gagan
Status: ASSIGNED → NEW

Comment 50

17 years ago
fix is in. 
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Did this fix cause the leak stats to go up?

Comment 52

17 years ago
I filed bug 67454 on the memory leak.

Comment 53

17 years ago
Still crashing on the mac build 2001-02-07-08-Mtrunk

Windows is okay

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 54

17 years ago
->pavlov
Assignee: gagan → pavlov
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9.1
(Assignee)

Comment 55

17 years ago
This code is no longer used.  This bug has been fixed by the new image library.
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 56

17 years ago
Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.