crashes [@ il_find_in_cache]

VERIFIED DUPLICATE of bug 59494

Status

()

Core
ImageLib
P3
normal
VERIFIED DUPLICATE of bug 59494
18 years ago
17 years ago

People

(Reporter: dbaron, Assigned: pnunn)

Tracking

({topcrash})

Trunk
topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm need info], crash signature, URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
Keywords: topcrash
Summary: crashes [@ il_find_in_cache → crashes [@ il_find_in_cache]
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Whiteboard: rtm
Target Milestone: --- → M18
(Assignee)

Comment 1

18 years ago
I'm putting this one on the [rtm need info] radar.
-pn
Whiteboard: rtm → [rtm need info]
(Assignee)

Comment 2

18 years ago
urls given by talkback reports:

http://www.silvercreekonline.com/
http://www.russianny.com/ 

-p
(Assignee)

Comment 3

18 years ago
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
(Assignee)

Comment 4

18 years ago
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

18 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.
(Assignee)

Comment 6

18 years ago
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

18 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.
(Assignee)

Comment 9

18 years ago
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

18 years ago
Created attachment 18668 [details]
1x1 gif
(Assignee)

Comment 11

18 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

18 years ago
I am not able to reproduct the crash loading this 0.gif file.(Windows NT)
(Assignee)

Comment 13

18 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

18 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

18 years ago
Created attachment 18684 [details]
1x1 gif from silvercreek site
(Assignee)

Comment 16

17 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
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 17

17 years ago
Marked as dupe of wrong bug#.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 18

17 years ago
Marking as dupe of #59494

*** This bug has been marked as a duplicate of 59494 ***
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 19

17 years ago
The fix for this bug caused the other, right?  Does that make it a duplicate?

Comment 20

17 years ago
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.