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
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
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: