64015 - crashes right after load, with an assertion failure in ilclient.cpp:647

Status: VERIFIED DUPLICATE of bug 61756

(Core :: Graphics: ImageLib, defect)

Description

[Ari Heitner]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; m18) Gecko/20001227
BuildID:    2000122708

I get:

Assertion failure: ic->clients == NULL, at ilclient.cpp:647

and then it aborts.

That line is:

643            ic->state = IC_ABORT_PENDING;
644            return;
645        }
646
647        PR_ASSERT(ic->clients == NULL);
648        il_scour_container(ic);
649
650
651        PR_FREEIF(ic->background_color);


Reproducible: Always
Steps to Reproduce:
Goto the page, maybe start to scroll a bit.

Actual Results:  She crashes, cap'n :)

Expected Results:  Not crashing?

Comment 1

[Ari Heitner]

Doesn't break in m18 (2000110321). I'll try the latest nightly against it. I'm
willing to believe it's gone away if it's not reproducible there.

Comment 2

[Doron Rosenberg (IBM)]

marking new, seeing this on a cvs build on linux as well from yesterday.

Comment 3

[Ari Heitner]

Unfortunately it's stopped crashing :) seems this was dependent on changing site
content. If i see this come up again I'll take a snapshot of the page for future
reference ... (shoulda done this the first time).

Comment 4

[Ari Heitner]

Finally was able to capture this one in gdb, thanks to a tip from dmose to
pick up the latest cvs snapshot. 

Here's the session (starting partway thru the rather long startup sequence):

Enabling Quirk StyleSheet
Document about:blank loaded successfully
WARNING: not calling OnDataAvailable, file nsAsyncStreamListener.cpp, line
410
[New Thread 14351 (LWP 20169)]
LWP 20163 exited.
Opening file cookperm.txt failed
Tripped breakpoint at 402e04a1 in LWP 20154 while waiting for SIGSTOP.
[New Thread 15376 (LWP 20194)]
Delayed SIGSTOP caught for LWP 20194.
LWP 20169 exited.
Enabling Quirk StyleSheet
JavaScript strict warning: 
http://www.jpost.com/ line 19: assignment to undeclared variable randomseed

JavaScript strict warning: 
http://www.jpost.com/ line 20: assignment to undeclared variable
randomNumber

WEBSHELL+ = 4
Opening file cookies.txt failed
Enabling Quirk StyleSheet
Assertion failure: ic->clients == NULL, at ilclient.cpp:647

Program received signal SIGABRT, Aborted.
[Switching to Thread 1024 (LWP 20152)]
0x4037b111 in kill () at ../../../dist/include/nsIPageSequenceFrame.h:112
112       }
(gdb) 

you can clearly see the assertion failure before the SIGABRT. Here's a
backtrace:

(gdb) bt
#0  0x4037b111 in kill () at
../../../dist/include/nsIPageSequenceFrame.h:112
#1  0x402dc9be in pthread_kill ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#2  0x402dce71 in raise () at
../../../dist/include/nsIPageSequenceFrame.h:112
#3  0x4037c551 in abort () at
../../../dist/include/nsIPageSequenceFrame.h:112
#4  0x40299c2a in PR_Assert (s=0x4006ad2e "ic->clients == NULL", 
    file=0x4006ab81 "ilclient.cpp", ln=647) at prlog.c:477
#5  0x4004f5ff in il_delete_container (ic=0x4239dbd0) at ilclient.cpp:647
#6  0x4004bce8 in IL_NetRequestDone (ic=0x4239dbd0, url=0x4239ddd0,
status=0)
    at if.cpp:1179
#7  0x400472b9 in NetReaderImpl::NetRequestDone (this=0x4239df70, 
    urls=0x4239ddd0, status=0) at ilNetReader.cpp:139
#8  0x4003c822 in ImageConsumer::OnStopRequest (this=0x4239dfc0, 
    channel=0x4239e038, aContext=0x0, status=0, aMsg=0x4018d670)
    at nsImageNetContextAsync.cpp:551
#9  0x41098f41 in nsDocumentOpenInfo::OnStopRequest (this=0x4239e328, 
    aChannel=0x4239e038, aCtxt=0x0, aStatus=0, errorMsg=0x4018d670)
    at nsURILoader.cpp:274
#10 0x40e7a19b in nsHTTPFinalListener::OnStopRequest (this=0x4239e2a8, 
    aChannel=0x4239e038, aContext=0x0, aStatus=0, aStatusArg=0x4018d670)
    at nsHTTPResponseListener.cpp:1167
#11 0x40eb4ec1 in InterceptStreamListener::OnStopRequest (this=0x4237da68, 
    channel=0x4239e038, ctxt=0x0, aStatus=0, aStatusArg=0x4018d670)
    at nsCachedNetData.cpp:1211
#12 0x40e6d3db in nsHTTPChannel::ResponseCompleted (this=0x4239e038, 
    aListener=0x4237da68, aStatus=0, aStatusArg=0x4018d670)
    at nsHTTPChannel.cpp:1923
#13 0x40e78f15 in nsHTTPServerListener::OnStopRequest (this=0x42393848, 
    channel=0x423899c4, i_pContext=0x4239e038, i_Status=0, 
    aStatusArg=0x4018d670) at nsHTTPResponseListener.cpp:729
#14 0x40e08650 in nsOnStopRequestEvent::HandleEvent (this=0x82cbc88)
    at nsAsyncStreamListener.cpp:300
#15 0x40e07b6c in nsStreamListenerEvent::HandlePLEvent (aEvent=0x82cbc94)
    at nsAsyncStreamListener.cpp:92
#16 0x40130591 in PL_HandleEvent (self=0x82cbc94) at plevent.c:576
#17 0x40130380 in PL_ProcessPendingEvents (self=0x80aee08) at plevent.c:509
#18 0x401323de in nsEventQueueImpl::ProcessPendingEvents (this=0x80aede0)
    at nsEventQueue.cpp:356
#19 0x407efd63 in event_processor_callback (data=0x80aede0, source=7, 
    condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#20 0x407ef965 in our_gdk_io_invoke (source=0x81dcd58, condition=G_IO_IN, 
    data=0x8250a10) at nsAppShell.cpp:58
#21 0x409c3bf0 in g_io_add_watch ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#22 0x409c52b9 in g_get_current_time ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#23 0x409c58c3 in g_get_current_time ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#24 0x409c5a5c in g_main_run ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#25 0x408ea457 in gtk_main ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#26 0x407f04d5 in nsAppShell::Run (this=0x80ada68) at nsAppShell.cpp:350
#27 0x4076f7ee in nsAppShellService::Run (this=0x80b5818)
    at nsAppShellService.cpp:407
---Type <return> to continue, or q <return> to quit--- 
#28 0x080569a8 in main1 (argc=1, argv=0xbffff7f4, nativeApp=0x0)
    at nsAppRunner.cpp:1019
#29 0x08057611 in main (argc=1, argv=0xbffff7f4) at nsAppRunner.cpp:1287
#30 0x4036be0c in __libc_start_main ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
(gdb) 

<whew> :)

well, someone ought to enjoy that ... 

i'd vote for anyone else following this to check it out quickly, since
jpost.com (for obvious reason) changes their content regularly and that does
seem to affect whether the crash happens.

Comment 5

[Fabian Guisset]

I recognize this stack trace as the one from bug 61756. Reporter can you confirm
plz? Thanks.

Comment 6

[Ari Heitner]

Yes, it is indeed a duplicate of 61756. Reading the comments on that one, it
looks like this has been reported a couple of times over.

Good to know there's a solid handle on this one.


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

Comment 7

[Diego]

Verified dupe of bug 61756: "crash stack: il_delete_container"