Closed
Bug 58071
Opened 24 years ago
Closed 24 years ago
crashes [@ il_find_in_cache]
Categories
(Core :: Graphics: ImageLib, defect, P3)
Core
Graphics: ImageLib
Tracking
()
M18
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]
Reporter | ||
Updated•24 years ago
|
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]
urls given by talkback reports:
http://www.silvercreekonline.com/
http://www.russianny.com/
-p
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
Comment 5•24 years ago
|
||
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
Reporter | ||
Comment 7•24 years ago
|
||
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.
http://t0.extreme-dm.com/0.gif
http://t0.extreme-dm.com/0.gif?tag=rny2&j=y&srw=1280&srb=24&rs=41&l=
will create the crash.
-p
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
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
I am not able to reproduct the crash loading this 0.gif file.(Windows NT)
Assignee | ||
Comment 13•24 years ago
|
||
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
Assignee | ||
Comment 14•24 years ago
|
||
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
Assignee | ||
Comment 15•24 years ago
|
||
Assignee | ||
Comment 16•24 years ago
|
||
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
Assignee | ||
Comment 17•24 years ago
|
||
Marked as dupe of wrong bug#.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 18•24 years ago
|
||
Marking as dupe of #59494
*** This bug has been marked as a duplicate of 59494 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 19•24 years ago
|
||
The fix for this bug caused the other, right? Does that make it a duplicate?
Updated•13 years ago
|
Crash Signature: [@ il_find_in_cache]
You need to log in
before you can comment on or make changes to this bug.
Description
•