60460 - mozilla coredumps when viewing the above page

Status: VERIFIED DUPLICATE of bug 61756

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

Description

[Shao Zhang]

Produced using nightly 2000111621 under Debian Linux.
When viewing the above site, mozilla core dumps.

Comment 1

[Matthias Versen [:Matti]]

wfm win2k build 2000111604

Comment 2

[R.K.Aa.]

either this is brand new - or random.
Didn't crash with linux installed build 2000111508

Comment 3

[R.K.Aa.]

Loads OK with 2000111621 as well. RH6.2+updates. WFM.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I see this on a RedHat 6.2 system + updates, Mozilla CVS build from the morning
of Nov 17.  Reassigning to networking based on the stack trace, confirming.

Stack:

#0  0x40306d21 in __kill () from /lib/libc.so.6
#1  0x402511f7 in raise (sig=6) at signals.c:65
#2  0x403080b8 in abort () at ../sysdeps/generic/abort.c:88
#3  0x4020b814 in PR_Assert (s=0x4004fcee "ic->clients == NULL",
    file=0x4004fb81 "ilclient.cpp", ln=648) at prlog.c:477
#4  0x4003d723 in il_delete_container (ic=0x876b338) at ilclient.cpp:648
#5  0x4003a9ff in IL_NetRequestDone (ic=0x876b338, url=0x876b550, status=0)
    at if.cpp:1179
#6  0x40037726 in NetReaderImpl::NetRequestDone (this=0x876b718, urls=0x876b550,
    status=0) at ilNetReader.cpp:141
#7  0x4002d4d8 in ImageConsumer::OnStopRequest (this=0x876b678, channel=0x876c250,
    aContext=0x0, status=0, aMsg=0x401391a8) at nsImageNetContextAsync.cpp:551
#8  0x40e4db2f in nsDocumentOpenInfo::OnStopRequest (this=0x876c428,
aChannel=0x876c250,
    aCtxt=0x0, aStatus=0, errorMsg=0x401391a8) at nsURILoader.cpp:274
#9  0x40cb5599 in nsHTTPFinalListener::OnStopRequest (this=0x876c5a0,
    aChannel=0x876c250, aContext=0x0, aStatus=0, aStatusArg=0x401391a8)
    at nsHTTPResponseListener.cpp:1159
#10 0x40c7ae85 in InterceptStreamListener::OnStopRequest (this=0x879b1c8,
    channel=0x876c250, ctxt=0x0, aStatus=0, aStatusArg=0x401391a8)
    at nsCachedNetData.cpp:1211
#11 0x40ca7a69 in nsHTTPChannel::ResponseCompleted (this=0x876c250,
aListener=0x879b1c8,
    aStatus=0, aStatusArg=0x401391a8) at nsHTTPChannel.cpp:1923
#12 0x40cb462a in nsHTTPServerListener::OnStopRequest (this=0x8770658,
    channel=0x876d3e4, i_pContext=0x876c250, i_Status=0, aStatusArg=0x401391a8)
    at nsHTTPResponseListener.cpp:729
#13 0x40c3b5bb in nsOnStopRequestEvent::HandleEvent (this=0x86f8550)
    at nsAsyncStreamListener.cpp:300
#14 0x40c3aa15 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x86f855c)
    at nsAsyncStreamListener.cpp:92
#15 0x400f0e7e in PL_HandleEvent (self=0x86f855c) at plevent.c:576
#16 0x400f0d19 in PL_ProcessPendingEvents (self=0x80a5d68) at plevent.c:509
#17 0x400f2970 in nsEventQueueImpl::ProcessPendingEvents (this=0x80a5d40)
    at nsEventQueue.cpp:356
#18 0x406b4dbf in event_processor_callback (data=0x80a5d40, source=8,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#19 0x406b4a7d in our_gdk_io_invoke (source=0x81c6248, condition=G_IO_IN,
data=0x81f55a0)
    at nsAppShell.cpp:58
#20 0x4086eaca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#21 0x40870186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#22 0x40870751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#23 0x408708f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#24 0x40798c69 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#25 0x406b5994 in nsAppShell::Run (this=0x80af1f8) at nsAppShell.cpp:335
#26 0x405d4fb5 in nsAppShellService::Run (this=0x80ac700) at
nsAppShellService.cpp:407
#27 0x80523fb in main1 (argc=1, argv=0xbffff8c4, nativeApp=0x0) at
nsAppRunner.cpp:1015
#28 0x8052d26 in main (argc=1, argv=0xbffff8c4) at nsAppRunner.cpp:1255
#29 0x403009cb in __libc_start_main (main=0x8052ba0 <main>, argc=1,
argv=0xbffff8c4,
    init=0x804c244 <_init>, fini=0x805edcc <_fini>, rtld_fini=0x4000ae60
<_dl_fini>,
    stack_end=0xbffff8bc) at ../sysdeps/generic/libc-start.c:92

Comment 5

[Shao Zhang]

forgot to mension that I am running the newest libc6(version 2.2). This could be
related.

Comment 6

[Matthew Cline]

I'm getting this bug on RedHat 6.1, kernel 2.2.14, with these libc and
linking related RPMs:

glibc-2.1.92-5
compat-glibc-6.2-2.1.3.2
glibc-devel-2.1.92-5
libc-5.3.12-31
binutils-2.10.0.24-5mdk

This is happening with the CVS build that I did yesterday.  This seems to
be happening to me an awful lot.

Comment 7

[Doron Rosenberg (IBM)]

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

Comment 8

[Doron Rosenberg (IBM)]

62331 has the exact same stacktrace, I duplicated it to this. It does have a
testcase and a talkback report.

Comment 9

[Matthew Cline]

Bug 61654 looks like a duplicate of this bug.  Also found a new site,
http://www.serc.rmit.edu.au/~ashelton/anime/, which appears to tickle
this bug.

Comment 10

[Bradley Baetz]

61654 probably is a dupe, but that bug has an attached (invalid) gif which
reproduces the assertion failure.

Comment 11

[timeless]

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

Comment 12

[timeless]

isn't this an imagelib bug?

Comment 13

[pnunn]

dupe

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

Comment 14

[pnunn]

actually this is a dupe of 61756.
    bug#62973 may end up also being a dupe of 61756, but though
     the stack is the same, the M.O. is different. It has a gif with
     one frame but a zillion loops specified.

Comment 15

[pnunn]

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

Comment 16

[Diego]

Verified dupe (same stack) of bug 61756: "crash stack: il_delete_container"