Closed Bug 58071 Opened 24 years ago Closed 24 years ago

crashes [@ il_find_in_cache]

Categories

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

defect

Tracking

()

VERIFIED DUPLICATE of bug 59494

People

(Reporter: dbaron, Assigned: pnunn)

References

()

Details

(Keywords: topcrash, Whiteboard: [rtm need info])

Crash Data

Attachments

(2 files)

Talback reports contain many crashes at il_find_in_cache, on both Windows and Linux. See the data on n.p.m.crash-data or http://www.mozilla.org/projects/seamonkey/reports/ns6analysis.html for details. It's the #7 topcrash on the branch and #8 on the trunk. Top of stack is (10-21 trunk line numbers): il_find_in_cache [d:\builds\seamonkey\mozilla\modules\libimg\src\ilclient.cpp line 396] il_get_container [d:\builds\seamonkey\mozilla\modules\libimg\src\ilclient.cpp line 439] IL_GetImage [d:\builds\seamonkey\mozilla\modules\libimg\src\if.cpp line 1913] ImageRequestImpl::Init [d:\builds\seamonkey\mozilla\gfx\src\nsImageRequest.cpp line 262] ImageGroupImpl::GetImage [d:\builds\seamonkey\mozilla\gfx\src\nsImageGroup.cpp line 285] nsFrameImageLoader::Init [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameImageLoader.cpp line 189] nsPresContext::StartLoadImage [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp line 1107]
Keywords: topcrash
Summary: crashes [@ il_find_in_cache → crashes [@ il_find_in_cache]
Status: NEW → ASSIGNED
Whiteboard: rtm
Target Milestone: --- → M18
I'm putting this one on the [rtm need info] radar. -pn
Whiteboard: rtm → [rtm need info]
I'm not able to reproduce the crash in my local N6 branch tree updated yesterday. (NT). Will verify if I have local changes in my tree, or missed some checkins. and will check on linux. -p
My fresh NT branch tree doesn't crash on either of these urls. I do get a js assert on www.russianny.com: ###!!! ASSERTION: NS_ENSURE_TRUE(mSessionHistory) failed: 'mSessionHistory', file d:\work2\mozilla\docshell\base\nsWebSh ell.cpp, line 535 JavaScript strict warning: http://www.russianny.com/mainfr.asp line 712: assignment to undeclared variable bv but ignoring it works fine. ------------------ However, on linux, I can see the crash on both urls. ??Why linux and not NT? If anyone has a mac build to test, I'd be interested in hearing the verdict. I'll be investigating. -p
All the crashes reported today using today's build seem to have come from windows NT/95. il_find_in_cache Stack Trace: il_find_in_cache [d:\builds\seamonkey\mozilla\modules\libimg\src\ilclient.cpp line 396] il_get_container [d:\builds\seamonkey\mozilla\modules\libimg\src\ilclient.cpp line 439] IL_GetImage [d:\builds\seamonkey\mozilla\modules\libimg\src\if.cpp line 1922] ImageRequestImpl::Init [d:\builds\seamonkey\mozilla\gfx\src\nsImageRequest.cpp line 262] ImageGroupImpl::GetImage [d:\builds\seamonkey\mozilla\gfx\src\nsImageGroup.cpp line 285] nsFrameImageLoader::Init [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameImageLoader.cpp line 189] nsPresContext::StartLoadImage [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp line 1107] nsHTMLImageLoader::StartLoadImage [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLImageLoader.cpp line 241] nsHTMLImageLoader::GetDesiredSize [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLImageLoader.cpp line 479] nsImageFrame::GetDesiredSize [d:\builds\seamonkey\mozilla\layout\html\base\src\nsImageFrame.cpp line 327] nsImageFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsImageFrame.cpp line 362] nsLineLayout::ReflowFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp line 922] nsBlockFrame::ReflowInlineFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 4369] nsBlockFrame::DoReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 4253] nsBlockFrame::DoReflowInlineFramesAuto [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 4187] nsBlockFrame::ReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 4133] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3268] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2957] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 1747] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp line 562] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp line 334] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3885] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3154] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2957] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 1747] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 716] CanvasFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp line 309] nsBoxToBlockAdaptor::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp line 871] nsBoxToBlockAdaptor::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp line 527] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsScrollBoxFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp line 379] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsContainerBox::LayoutChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp line 597] nsGfxScrollFrameInner::LayoutBox [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1030] nsGfxScrollFrameInner::Layout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1117] nsGfxScrollFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1038] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 775] nsGfxScrollFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 744] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 716] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp line 546] nsHTMLReflowCommand::Dispatch [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp line 146] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5146] ReflowEvent::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5029] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 581] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 517] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1051] Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libimg/src/ilclient. cpp line : 396 Build: 2000110109 CrashDate: 2000-11-01 UptimeMinutes: 51 Total: 56 OS: Windows NT 5.0 build 2195 URL: Incident ID: 20231102 Comment: Build: 2000110109 CrashDate: 2000-11-01 UptimeMinutes: 5 Total: 5 OS: Windows NT 5.0 build 2195 URL: Incident ID: 20224418 Comment: I was running the Browser Buster and Mozilla crashed. Here's the callstack from DRWTSN32.LOG. Notice the suspicious pointer values eax=f0f0f0f0 and esi=f0f0f0f0.State Dump for Thread Id 0x398eax=f0f0f0f0 ebx=03a56038 ecx=0000a4fa edx=048bf739 Build: 2000110109 CrashDate: 2000-11-01 UptimeMinutes: 21 Total: 21 OS: Windows 95 4.0 build 67306684 URL: Unsure Incident ID: 20220288 Comment: Running the "browser buster" pages. Running the "browser buster" pages.
I'm getting a different backtrace. #0 0x40388d41 in __kill () from /lib/libc.so.6 #1 0x402d3217 in raise (sig=6) at signals.c:65 #2 0x4038a0d8 in abort () at ../sysdeps/generic/abort.c:88 #3 0x40291814 in PR_Assert (s=0x40064b6e "ic->clients == NULL", file=0x40064a01 "ilclient.cpp", ln=648) at prlog.c:477 #4 0x4004bd9c in il_delete_container (ic=0x42bed470) at ilclient.cpp:648 #5 0x4004877e in IL_NetRequestDone (ic=0x42bed470, url=0x42b3f370, status=0) at if.cpp:1188 #6 0x40043d9b in NetReaderImpl::NetRequestDone (this=0x42b479a8, urls=0x42b3f370, status=0) at ilNetReader.cpp:141 #7 0x4003942e in ImageConsumer::OnStopRequest (this=0x42b47950, channel=0x42bedb00, aContext=0x0, status=0, aMsg=0x4017ea30) at nsImageNetContextAsync.cpp:551 #8 0x40f93093 in nsDocumentOpenInfo::OnStopRequest (this=0x42bed9d8, aChannel=0x42bedb00, aCtxt=0x0, aStatus=0, errorMsg=0x4017ea30) at nsURILoader.cpp:274 #9 0x40de21d6 in nsHTTPFinalListener::OnStopRequest (this=0x42bedde0, aChannel=0x42bedb00, aContext=0x0, aStatus=0, aStatusArg=0x4017ea30) at nsHTTPResponseListener.cpp:1159 #10 0x40dadf2a in InterceptStreamListener::OnStopRequest (this=0x42d21e78, channel=0x42bedb00, ctxt=0x0, aStatus=0, aStatusArg=0x4017ea30) at nsCachedNetData.cpp:1206 #11 0x40da4a51 in nsHTTPChunkConv::OnStopRequest (this=0x42d58830, aChannel=0x42bedb00, aContext=0x0, aStatus=0, aStatusArg=0x4017ea30) at nsHTTPChunkConv.cpp:108 #12 0x40dd5ca8 in nsHTTPChannel::ResponseCompleted (this=0x42bedb00, aListener=0x42d58830, aStatus=0, aStatusArg=0x4017ea30) at nsHTTPChannel.cpp:1923 #13 0x40de10a1 in nsHTTPServerListener::OnStopRequest (this=0x84afa80, channel=0x42bce3ac, i_pContext=0x42bedb00, i_Status=0, aStatusArg=0x4017ea30) at nsHTTPResponseListener.cpp:729 And the url when crashing is: http://silvercreekonline.com/cgi-bin/newcount?silv491&noshow which is a cgi counter. noshow sets it up to not show the counter image, but instead a 1x1 gif with b/w color map. The url www.russianny.com doesn't crash at all for me in the debugger. I'll check it again tomorrow. -pn
Well, the PR_ASSERT is a no-op in non-DEBUG builds, and it causes the program to terminate in debug builds, so you're seeing it exit earlier. Maybe if you fix whatever is causing the assert, then the crash will go away too? If not, then at least you'll see the crash.
ok. Lets make this simple. The crash occurs because of a 1x1 gif image. The image could be used for spacing or tracking users. I'll attach the gif. -pn
Attached image 1x1 gif (deleted) —
We don't crash on all 1x1's. I'm looking at what makes these 1x1's special. It looks like the 1x1 on the russianny site is issued from a marketing statistics firm, which confirms the idea these images are used to track users whether they allow cookies or not. -p
I am not able to reproduct the crash loading this 0.gif file.(Windows NT)
Everytime I load the attached gif in a linux N6 build (current to yesterday) I get a crash. The image has no trailer byte on the end of the image. I'm not concerned about the bad image, but I am concerned that we have a race condition where the the data stream end is somehow out of synch with our clean up. -p
Both of the sites have 1x1 images that trigger an error parsing the image data. I haven't nailed this one down yet, but I think the crash is caused by a race between the gif decoder freeing up stuff after it hits the error condition and the stream handling stuff that is cleaning up after such a short data stream.... and no one wins. In short, I'm working to get a fix as soon as possible, but I don't think the train should wait for this bug fix. It should only occur with 1x1 malformed gifs. I don't see the crash on NT. I do see it on linux. -p
Attached image 1x1 gif from silvercreek site (deleted) —
patch from 55997 also fixes this crash on linux. marking as duplicate. -pn *** This bug has been marked as a duplicate of 55997 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Marked as dupe of wrong bug#.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Marking as dupe of #59494 *** This bug has been marked as a duplicate of 59494 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
The fix for this bug caused the other, right? Does that make it a duplicate?
Verified Duplicate
Status: RESOLVED → VERIFIED
Crash Signature: [@ il_find_in_cache]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: