Closed Bug 59494 Opened 24 years ago Closed 24 years ago

segfault @ nsCSSFrameConstructor::CantRenderReplacedElement

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jens-uwe, Assigned: pnunn)

References

()

Details

(Keywords: crash)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m18) Gecko/20001107
BuildID:    2000110721

On this URL Mozilla shows abit but crashes then.

Reproducible: Always
Steps to Reproduce:
1. go to www.mobildiscount.de
2. watch mozilla crashing

Actual Results:  1. mozilla crashes

Expected Results:  mozilla should survive this page and display it correctly

Page is rendered just fine with konqueror and Netscape 4.x.

Here is the output of mozilla -g and "where"

Starting program: /home/jur/ftp/test/package/./mozilla-bin
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols found)...[New
Thread 32219 (manager thread)]
[New Thread 32218 (initial thread)]
[New Thread 32221]
[New Thread 32222]
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
Document about:blank loaded successfully
[Switching to Thread 32221]
[Switching to Thread 32218 (initial thread)]

Program received signal SIGSEGV, Segmentation fault.
0x40b7b124 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
(gdb) where
#0  0x40b7b124 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#1  0x40c7a742 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#2  0x40a4f3e9 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#3  0x400c39b3 in PL_HandleEvent () from /home/jur/ftp/test/package/libxpcom.so
#4  0x400c38d6 in PL_ProcessPendingEvents () from
/home/jur/ftp/test/package/libxpcom.so
#5  0x400c462d in nsEventQueueImpl::ProcessPendingEvents () from
/home/jur/ftp/test/package/libxpcom.so
#6  0x4049de0f in NSGetModule () from
/home/jur/ftp/test/package/components/libwidget_gtk.so
#7  0x4049dbcd in NSGetModule () from
/home/jur/ftp/test/package/components/libwidget_gtk.so
#8  0x40650340 in g_io_unix_dispatch (source_data=0x8260238,
current_time=0xbffff2d0, user_data=0x8260210) at giounix.c:135
#9  0x40651bd6 in g_main_dispatch (dispatch_time=0xbffff2d0) at gmain.c:656
#10 0x40652203 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#11 0x406523cc in g_main_run () at gmain.c:884
#12 0x4057100c in gtk_main () at gtkmain.c:807
#13 0x4049e2fc in NSGetModule () from
/home/jur/ftp/test/package/components/libwidget_gtk.so
#14 0x4044ab5a in inflate_mask () from
/home/jur/ftp/test/package/components/libnsappshell.so
#15 0x804e275 in JS_PushArguments ()
#16 0x804e845 in JS_PushArguments ()
#17 0x4026ba5e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93
wfm with 2000110720 win32 trunk
I crash all the time today, with 2000110721
Sometimes while page loads - sometimes while i scroll - a non-debug build shows
exactly same backtrace. Confirming bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Adding keywords. This bug is severe..close to a blocker.
I crash on lot of sites which used to work OK up till today.
Keywords: crash, regression
R.K.Aa: for me the same, todays nightly crashes quite often :-/
I guess this is "just" one top crasher...
layout?
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen
Correcting URL-field and adding another crasher:
http://www.itavisen.no
On http://www.itavisen.no I see:

Enabling Quirk StyleSheet
###!!! ASSERTION: frame already has posted event:
'!*FindPostedEventFor(aFrame)', file
/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 918
###!!! Break: at file
/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 918
###!!! ASSERTION: frame already has posted event:
'!*FindPostedEventFor(aFrame)', file
/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 918
###!!! Break: at file
/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 918
JavaScript strict warning: 
chrome://navigator/content/navigator.js line 2030: reference to undefined
property window._content.HTTPIndex

Document http://www.itavisen.no/ loaded successfully
WARNING: not calling OnDataAvailable, file
/builds/seamonkey/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp, line 406

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 6757)]


And then the stack is:

#0  0x415560d4 in nsCSSFrameConstructor::CantRenderReplacedElement (
    this=0x8504e58, aPresShell=0x85f0230, aPresContext=0x8521bb8, 
    aFrame=0x8606e7c)
    at
/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:10474
	parentFrame = (nsIFrame *) 0x417213f3
	styleContext = {mRawPtr = 0x0}
	content = {mRawPtr = 0x0}
	tag = {mRawPtr = 0x0}
	rv = 0
	listName = {mRawPtr = 0xbffff0f8}
	placeholderFrame = (nsIFrame *) 0xbffff110
	presShell = {mRawPtr = 0x8065420}
	firstChild = (nsIFrame *) 0x418896f8
	frameList = {mFirstChild = 0x85f0230}
#1  0x416e654a in StyleSetImpl::CantRenderReplacedElement (this=0x8504de8, 
    aPresContext=0x8521bb8, aFrame=0x8606e7c)
    at /builds/seamonkey/mozilla/layout/base/src/nsStyleSet.cpp:1247
	this = (StyleSetImpl *) 0x8504de8
	shell = {mRawPtr = 0x85f0230}
#2  0x413e3aa8 in FrameManager::HandlePLEvent (aEvent=0x873c990)
    at /builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp:870
	frameManager = (FrameManager *) 0x8502268
#3  0x401250bc in PL_HandleEvent (self=0x873c990)
    at /builds/seamonkey/mozilla/xpcom/threads/plevent.c:576
	result = (void *) 0x873c990
#4  0x40124ed5 in PL_ProcessPendingEvents (self=0x80a9878)
    at /builds/seamonkey/mozilla/xpcom/threads/plevent.c:509
	count = 1
	event = (PLEvent *) 0x873c990
#5  0x40126e1a in nsEventQueueImpl::ProcessPendingEvents (this=0x80a9850)
    at /builds/seamonkey/mozilla/xpcom/threads/nsEventQueue.cpp:356
	correctThread = 1
#6  0x40789d10 in event_processor_callback (data=0x80a9850, source=8, 
    condition=GDK_INPUT_READ)
    at /builds/seamonkey/mozilla/widget/src/gtk/nsAppShell.cpp:158
	eventQueue = (class nsIEventQueue *) 0x80a9850
...
Do you *know* that this bug didn't happen in the 2000-11-07-08 build?
Here's the stack for the assertion:

#0  nsDebug::Assertion (aStr=0x4182bc00 "frame already has posted event", 
    aExpr=0x4182bbe3 "!*FindPostedEventFor(aFrame)", 
    aFile=0x4182b920
"/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp", aLine=918)
at /builds/seamonkey/mozilla/xpcom/base/nsDebug.cpp:191
#1  0x413e3c4e in FrameManager::CantRenderReplacedElement (this=0x42732560, 
    aPresContext=0x4317ac08, aFrame=0x43154dbc)
    at /builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp:918
#2  0x414197ce in PresShell::CantRenderReplacedElement (this=0x4315b1a8, 
    aPresContext=0x4317ac08, aFrame=0x43154dbc)
    at /builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp:3264
#3  0x413f7f6a in nsImageFrame::UpdateImage (this=0x43154dbc, 
    aPresContext=0x4317ac08, aStatus=7, aClosure=0x43154de8)
    at /builds/seamonkey/mozilla/layout/html/base/src/nsImageFrame.cpp:252
#4  0x413f7cde in nsImageFrame::UpdateImageFrame (aPresContext=0x4317ac08, 
    aLoader=0x43154de8, aFrame=0x43154dbc, aClosure=0x43154de8, aStatus=7)
    at /builds/seamonkey/mozilla/layout/html/base/src/nsImageFrame.cpp:200
#5  0x413f07e9 in nsHTMLImageLoader::Update (this=0x43154de8, 
    aPresContext=0x4317ac08, aFrame=0x43154dbc, aStatus=7)
    at /builds/seamonkey/mozilla/layout/html/base/src/nsHTMLImageLoader.cpp:167
#6  0x413f073a in nsHTMLImageLoader::ImageLoadCB (aPresContext=0x4317ac08, 
    aLoader=0x43166480, aFrame=0x43154dbc, aClosure=0x43154de8, aStatus=7)
    at /builds/seamonkey/mozilla/layout/html/base/src/nsHTMLImageLoader.cpp:132
#7  0x41694fb8 in nsFrameImageLoader::NotifyFrames (this=0x43166480, 
    aIsSizeUpdate=0)
    at /builds/seamonkey/mozilla/layout/base/src/nsFrameImageLoader.cpp:575
#8  0x41694e4b in nsFrameImageLoader::Notify (this=0x43166480, 
    aImageRequest=0x433e6f08, aImage=0x0, 
    aNotificationType=nsImageNotification_kImageComplete, aParam1=0, aParam2=0, 
    aParam3=0x0)
    at /builds/seamonkey/mozilla/layout/base/src/nsFrameImageLoader.cpp:507
#9  0x4003efd4 in ns_observer_proc (aSource=0x433e6fc8, aMsg=7, 
    aMsgData=0xbfffedc8, aClosure=0x433e6f08)
    at /builds/seamonkey/mozilla/gfx/src/nsImageRequest.cpp:112
#10 0x4004fd35 in XP_NotifyObservers (inObserverList=0x431dc5a0, inMessage=7, 
    ioData=0xbfffedc8)
    at /builds/seamonkey/mozilla/modules/libutil/src/obs.c:259
#11 0x40046c6a in il_image_complete_notify (ic=0x431b8cb0)
    at /builds/seamonkey/mozilla/modules/libimg/src/if.cpp:327
#12 0x400491de in il_image_complete (ic=0x431b8cb0)
    at /builds/seamonkey/mozilla/modules/libimg/src/if.cpp:1644
#13 0x4004687e in ImgDCallbk::ImgDCBHaveImageAll (this=0x4333aeb0)
    at /builds/seamonkey/mozilla/modules/libimg/src/if.cpp:189
#14 0x41dc53d4 in il_gif_complete (ic=0x431b8cb0)
    at /builds/seamonkey/mozilla/modules/libimg/gifcom/gif.cpp:1650
#15 0x41dc5b12 in GIFDecoder::ImgDComplete (this=0x431ee2d0)
    at /builds/seamonkey/mozilla/modules/libimg/gifcom/nsGIFDecoder.cpp:114
#16 0x400489fa in IL_StreamComplete (ic=0x431b8cb0, is_multipart=0)
    at /builds/seamonkey/mozilla/modules/libimg/src/if.cpp:1347
#17 0x40043ca1 in NetReaderImpl::StreamComplete (this=0x431a2c90, 
    is_multipart=0)
    at /builds/seamonkey/mozilla/modules/libimg/src/ilNetReader.cpp:131
#18 0x40039f40 in ImageConsumer::OnStopRequest (this=0x43329130, 
    channel=0x4319c1c0, aContext=0x0, status=0, aMsg=0x401849c8)
    at /builds/seamonkey/mozilla/gfx/src/nsImageNetContextAsync.cpp:545
#19 0x40fef412 in nsDocumentOpenInfo::OnStopRequest ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#20 0x40e1dc63 in nsHTTPFinalListener::OnStopRequest ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#21 0x40e11014 in nsHTTPChannel::ResponseCompleted ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#22 0x40e1aa9f in nsHTTPCacheListener::OnStopRequest ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#23 0x40df2f2b in nsDiskCacheRecordChannel::OnStopRequest ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#24 0x40dad30f in nsOnStopRequestEvent::HandleEvent ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#25 0x40dac870 in nsStreamListenerEvent::HandlePLEvent ()
    at ../../../dist/include/nsIPageSequenceFrame.h:112
#26 0x401250bc in PL_HandleEvent (self=0x83b9608)
...
Undoing (by commenting out the release) my leak fix to nsDeviceContext.cpp
didn't fix this.
I know 100% certain i was there with a downloaded SEA build from the 6th, and
did not crash then. (Checked timestamps in history-file to make sure.)
I crash on both of the sites given with linux trunk 2000-11-07-08.

linux trunk 2000-11-06-08 loads both sites with no problems.
One suspicious change in that time period looks like mkaply's change to gif.cpp
for bug 55997.  cc:ing mkaply and pnunn.
crash at www.penny-arcade.com in bug 59510 can be a dup of this.
I just reverted gif.cpp back to rev. 1.34 in my tree and loaded
http://www.itavisen.no three times in a row.  Previously I was crashing on it
most of the time.

Based on that, assigning to ImageLib (although it could still be a problem in
layout, I guess), and also cc:ing tor since he was also somewhat involved in bug
55997.
Assignee: clayton → pnunn
Component: Layout → ImageLib
QA Contact: petersen → tpreston
Bummer. That fixes other crashes. 
The crash occurs on an image in the top frame:
http://www.mobildiscount.de/images/bestellung.gif

Talkback: TB20664575W
ahh and the sinner at itavisen.no is
http://www.itavisen.no/ads/Stepstone1.gif
*** Bug 59510 has been marked as a duplicate of this bug. ***
-All three gif's are GIF89a
-First two gifs are both made up of only one frame, set to 0ms
-The third one (rspy.gif) consists of several frames, most transparent, and all
set to 0ms.

(frame info according to the Gimp.)
The 3 problematic pictures still crashes with the nightly from november the 8th.
*** Bug 59635 has been marked as a duplicate of this bug. ***
Noone has asked me to back this out yet. Should I?

There is probably another bug at work here that my fix is pointing out, but at 
least we would stop getting bug reports.
i reopened bug 59635 since a Windows user also sees that crash, but not the one
in this bug. 59635 may have more crashes lurking than only the gif's.
I'm running build 2000110904 on Win98 and if I look at the three problem images,
they begin to render then are replaced w/ their URLs.
Note that this bug is active in the installer-installed linux builds, but not in
the sea.tar.gz builds you install from HD.

(Same kind of difference between the builds can be observed with several other
bugs now:
SEA builds don't have a build-ID, installer build has.
SEA builds talkback is horked, installer builds work.
SEA builds sidebar-tabs work, installer build's is dead (modern, bug 59613)
Etc.etc.etc.)
kaply:

yep, would you back out the change to the minimum timer delay?
I'll mention it in bug#55997.

-p
I have backed out my change from:

http://bugzilla.mozilla.org/show_bug.cgi?id=55997

I still believe the code in 55997 is correct and that this new bug showed off 
another bug.
I think we are hitting some race conditions.
Setting the timer to a minimum delay buys us
a little time...so to speak.

-p
This bug should have been cleared up
by mkaply backing out his patch.

I'm keeping this open until we find how
to solve both problems.
-p
Status: NEW → ASSIGNED
*** Bug 61172 has been marked as a duplicate of this bug. ***
*** Bug 39310 has been marked as a duplicate of this bug. ***
*** Bug 58071 has been marked as a duplicate of this bug. ***
This seems like the only bug that is not a dup of the [@ il_find_in_cache]
crash, so adding comments and topcrash keyword here.  Although this is a Linux
bug, the crash is also on Windows.  It is actually the #4 topcrash with the
official RTM build for Windows...so changing the OS to All.  Sorry if I got the
wrong bug, but it was the only one all the dups pointed to.  Here are a list of
URLs users submitted in the talkback reports:
http://www.antena1.ro
http://www.chetbrzezinski.com
http://www.geocities.com:0080/Heartland/Park/8172
http://www.sabetv.com
http://www.zakzak.co.jp/
landsend.com
socageneral.com
www.amdzone.com
www.cdcpoint.it
www.db3k.com
www.dialpad.com
www.kingston.com/
www.lomasdellago.cl
www.nasdaq.com
www.nosolomusica.telelcinco.es
www.nydeerhunters.homestead.com
www.sassooninteractive.com.sg
www.tripod.com
youcann.org
Keywords: topcrash
OS: Linux → All
Summary: Mozilla crashes reproducible → Mozilla crashes reproducible [@ il_find_in_cache]
couple 'o reloads of http://www.antena1.ro/ seem to get me crashed...
It is easily reproducible in the following URL
   http://clubs.yahoo.com/clubs/israelishoppingclub


Stack Trace, Other possible URL's and User Comments.
        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::UpdateURLSpec       
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLImageLoader.cpp  line 
262] 
         nsImageBoxFrame::UpdateImage   
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp  line 267] 
         nsImageBoxFrame::DidSetStyleContext    
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp  line 338] 
         nsFrame::SetStyleContext       
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp  line 479] 
         FrameManager::ReResolveStyleContext    
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp  line 1501] 
         FrameManager::ReResolveStyleContext    
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp  line 1643] 
         FrameManager::ReResolveStyleContext    
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp  line 1643] 
         FrameManager::ComputeStyleChangeFor    
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp  line 1886] 
         nsCSSFrameConstructor::AttributeChanged        
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp  
line 10079] 
         StyleSetImpl::AttributeChanged 
[d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp  line 1195] 
         PresShell::AttributeChanged    
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 4297] 
         nsXULDocument::AttributeChanged        
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp  line 1652] 
         nsXULElement::SetAttribute     
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp  line 2780] 
         nsXULElement::SetAttribute     
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp  line 1250] 
         ElementSetAttribute    
[d:\builds\seamonkey\mozilla\dom\src\coreDOM\nsJSElement.cpp  line 250] 
         js_Invoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
822] 
         js_Interpret   [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
2623] 
         js_Invoke      [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 
838] 
         nsXPCWrappedJSClass::CallMethod        
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp  line 
778] 
         nsXPCWrappedJS::CallMethod     
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp  line 319] 
         PrepareAndDispatch     
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp  
line 102] 
         SharedStub     
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp  
line 124] 
         nsBrowserInstance::OnStateChange       
[d:\builds\seamonkey\mozilla\xpfe\browser\src\nsBrowserInstance.cpp  line 1998] 
         nsDocLoaderImpl::FireOnStateChange     
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 1254] 
         nsDocLoaderImpl::doStopDocumentLoad    
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 713] 
         nsDocLoaderImpl::DocLoaderIsEmpty      
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 618] 
         nsDocLoaderImpl::DocLoaderIsEmpty      
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 623] 
         nsDocLoaderImpl::OnStopRequest 
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 555] 
         nsLoadGroup::RemoveChannel     
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp  line 583] 
         nsHTTPChannel::ResponseCompleted       
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp  line 
1954] 
         nsHTTPServerListener::OnStopRequest    
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p  line 730] 
         nsOnStopRequestEvent::HandleEvent      
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp  line 
302] 
         nsStreamListenerEvent::HandlePLEvent   
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp  line 
106] 
         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] 
         KERNEL32.DLL + 0x2222f (0xbff9222f)  
         0x00658b54  
 
        Source File : 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libimg/src/ilclient.
cpp line : 396

         URL: Trying
         URL: WWW.cwcom.net
         URL: fbireviews.gamehosts.com
         URL: http://64.45.60.64/poems/29/poem_291453.html
         URL: http://www.amdzone.com
         URL: http://www.gws_bong.homestead.com/
         URL: http://www.interlog.com/~tcharron/palm/upgradeservice.html
         URL: http://www.marilyn-manson.com/cgi-bin/ubb/Ultimate.cgi
         URL: http://www.overclockers.com.au/techstuff/a_dos_me/
         URL: http://www.tvguide.com/listings/setup/Localize.asp
         URL: img.3250.dll
         URL: mail.uchile.cl
         URL: once-upon-a-forrest.com
         URL: www.act.org
         URL: www.bomis.com
         URL: www.coolinfo.com
         URL: www.javapowered.com
         URL: www.netscape.co.uk
         URL: www.nsk.su
         URL: www.romainia.com
         URL: www.scruffypup.com
         URL: www.soviet-invasion.com
         URL: www.tweakmax.com
         URL: www.westpac.com.au
         URL: www.world-of-nintendo.com
         URL: www.zgeek.com
        Comment:  I searched for a topic and I clicked on the first one listed. 
The topic was alladvantage.
        Comment:  Going back to IE5.5 SP1 at least this doesn't crash every 2 
secs
        Comment:  browsing
Summary: Mozilla crashes reproducible [@ il_find_in_cache] → RTM crash #4 - Mozilla crashes reproducible (ilclient.cpp, line : 396) [@ il_find_in_cache] [@
Is there a difference between "Open File" and "Open Web Location -> Choose File"??
There is a strange behavior with the flag-picture in the mentioned URL
http://clubs.yahoo.com/clubs/israelishoppingclub:
Save the picture of the flag (perhaps with a different browser;) into a file on
your hard disk. Now Open it with "open file" and everything works fine. Now open
the same file with "Open Web Location -> choose file", and the picture takes
forever to load. It won't crash, but it simply does not finish loading!
I am not sure, if this problem is connected to this bug or a different one, but
perhaps it helps! The Picture URL is
http://id.yimg.com/d/d1593195/g/1dafcdc0.gif and I am using Mozilla Build
2000120306 for Linux.

JU:

Please don't confuse the issue. could you open a new bug? 
thanks.
Summary: RTM crash #4 - Mozilla crashes reproducible (ilclient.cpp, line : 396) [@ il_find_in_cache] [@ → RTM crash #4 - Mozilla crashes reproducible (ilclient.cpp, line : 396) [@ il_find_in_cache]
pnunn:
are you sure, that this is a different bug? I was using a picture in the
crashing webpage mentioned in the comment by namachi@netscape.com
*** Bug 61931 has been marked as a duplicate of this bug. ***
Summary: RTM crash #4 - Mozilla crashes reproducible (ilclient.cpp, line : 396) [@ il_find_in_cache] → RTM crash #4 - Mozilla crashes reproducible [@ il_find_in_cache] (ilclient.cpp, line : 396)
jens:
The gif image you mention is an odd file. It is set up 
as an animation with 1000 loops. but it only has one frame
in it. There is also a problem accessing it directly from
the server. The server doesn't want to give permissions for
the directory or the file.

This sounds totally unrelated the crash bug described in the
bug report.
-p
correction. 10000 loops....of one frame.
-p
I'm not able to get this to crash on either my
N6 or mozilla (updated 12-12-00). Is it possible that
this crash occurred during the short time period that
the patch for 55997 was checked in. This period is
11-06 to 11-13.

Is anyone still seeing this bug?(..with a current build....)
-p
pnunn: thanks for your informations about the loops in the picture, I think I'll
file a new bug about it.

I still see the crasher on the http://clubs.yahoo.com/clubs/israelishoppingclub
with the 2000121209 build for Linux.Crashes every time...
maybe this on linux only?
my pc tests were on nt.
-p
pnunn: 
I just tried the isralishoppingclub-page on Win98 with the Mozilla build from
the 9th of december. And it also crashed all times on this page!! Therefore I
doubt that it is a Linux only issue. 
I use the precompiled versions from the mozilla page, nothing self compiled.
Maybe this is the reason?

I add some debugger informations from the Linux version, maybe they help to find
the reason?

#29 0x400d56f6 in nsXPTCStubBase::Stub7 () from
/home/jur/ftp/test/package/libxpcom.so
#30 0x40e323bc in NSGetModule () from
/home/jur/ftp/test/package/components/libmozbrwsr.so
#31 0x40994786 in NSGetModule () from
/home/jur/ftp/test/package/components/liburiloader.so
#32 0x40993f70 in NSGetModule () from
/home/jur/ftp/test/package/components/liburiloader.so
#33 0x40993e56 in NSGetModule () from
/home/jur/ftp/test/package/components/liburiloader.so
#34 0x40993e77 in NSGetModule () from
/home/jur/ftp/test/package/components/liburiloader.so
#35 0x40993d1b in NSGetModule () from
/home/jur/ftp/test/package/components/liburiloader.so
#36 0x408a09de in NSGetModule () from
/home/jur/ftp/test/package/components/libnecko.so
#37 0x408ce1f8 in NSGetModule () from
/home/jur/ftp/test/package/components/libnecko.so
#38 0x408d4c6d in NSGetModule () from
/home/jur/ftp/test/package/components/libnecko.so
#39 0x4089178c in NSGetModule () from
/home/jur/ftp/test/package/components/libnecko.so
#40 0x408911a4 in NSGetModule () from
/home/jur/ftp/test/package/components/libnecko.so
#41 0x400c39e3 in PL_HandleEvent () from /home/jur/ftp/test/package/libxpcom.so
#42 0x400c3906 in PL_ProcessPendingEvents () from
/home/jur/ftp/test/package/libxpcom.so
#43 0x400c465d in nsEventQueueImpl::ProcessPendingEvents () from
/home/jur/ftp/test/package/libxpcom.so
#44 0x404a2e5f in NSGetModule () from
/home/jur/ftp/test/package/components/libwidget_gtk.so
#45 0x404a2c1d in NSGetModule () from
/home/jur/ftp/test/package/components/libwidget_gtk.so
#46 0x40655340 in g_io_unix_dispatch (source_data=0x825e370,
current_time=0xbffff2d0, user_data=0x825e348) at giounix.c:135
#47 0x40656bd6 in g_main_dispatch (dispatch_time=0xbffff2d0) at gmain.c:656
#48 0x40657203 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#49 0x406573cc in g_main_run () at gmain.c:884
#50 0x4057600c in gtk_main () at gtkmain.c:807
#51 0x404a334c in NSGetModule () from
/home/jur/ftp/test/package/components/libwidget_gtk.so
#52 0x40450c1a in inflate_mask () from
/home/jur/ftp/test/package/components/libnsappshell.so
#53 0x804e275 in JS_PushArguments ()
#54 0x804e875 in JS_PushArguments ()
#55 0x4026fa5e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93
(gdb) 

And now the stuff until line 29 ;-)

Starting program: /home/jur/ftp/test/package/./mozilla-bin 
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols found)...[New
Thread 31503 (manager thread)]
[New Thread 31502 (initial thread)]
[New Thread 31504]
[New Thread 31505]
in SetSecurityButton
Document about:blank loaded successfully
[New Thread 31513]
[Switching to Thread 31504]
[Switching to Thread 31502 (initial thread)]

Program received signal SIGSEGV, Segmentation fault.
0x40035da3 in ImgDCallbk::CreateInstance () from
/home/jur/ftp/test/package/libgkgfx.so
(gdb)  where
#0  0x40035da3 in ImgDCallbk::CreateInstance () from
/home/jur/ftp/test/package/libgkgfx.so
#1  0x40035e4d in il_get_container () from
/home/jur/ftp/test/package/libgkgfx.so
#2  0x40035260 in IL_GetImage () from /home/jur/ftp/test/package/libgkgfx.so
#3  0x4002e079 in ImageRequestImpl::Init () from
/home/jur/ftp/test/package/libgkgfx.so
#4  0x400287b6 in ImageGroupImpl::GetImage () from
/home/jur/ftp/test/package/libgkgfx.so
#5  0x40c584e5 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#6  0x40c6c902 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#7  0x40a5a6f1 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#8  0x40a5a770 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#9  0x40bfc20d in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#10 0x40bfc3a8 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#11 0x40a4cf8d in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#12 0x40a53991 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#13 0x40a53f89 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#14 0x40a53f89 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#15 0x40a540f4 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#16 0x40b7f3a7 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#17 0x40c852f9 in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#18 0x40a769bf in NSGetModule () from
/home/jur/ftp/test/package/components/libgklayout.so
#19 0x4081efc5 in NSGetModule () from
/home/jur/ftp/test/package/components/librdf.so
#20 0x4080f10d in NSGetModule () from
/home/jur/ftp/test/package/components/librdf.so
#21 0x4080b2f3 in NSGetModule () from
/home/jur/ftp/test/package/components/librdf.so
#22 0x403cd62e in NS_NewScriptDocumentType () from
/home/jur/ftp/test/package/libjsdom.so
#23 0x40124ac5 in js_Invoke () from /home/jur/ftp/test/package/libmozjs.so
#24 0x4012b9f5 in js_Interpret () from /home/jur/ftp/test/package/libmozjs.so
#25 0x40124b10 in js_Invoke () from /home/jur/ftp/test/package/libmozjs.so
#26 0x4076ac4b in NSGetModule () from
/home/jur/ftp/test/package/components/libxpconnect.so
#27 0x407695f5 in NSGetModule () from
/home/jur/ftp/test/package/components/libxpconnect.so
#28 0x400d55e4 in XPTC_InvokeByIndex () from
/home/jur/ftp/test/package/libxpcom.so
thanks for the info.
I'll try a release build to see if I can get the crash.
And the 2 stack traces look like different animals. hmmmm.
this is starting to look interesting.....
-p
okay.
everybody out of the pool.
This bug report has been mutated to cover another
bug... or bugs. 

I'm closing the bug for the issues dealing with mKaply's checkin
and dbarons comments.

The bug starting with jpatel's comments and changes gets a new
bug report. The new bug report is 62966.

Lets keep this simple folks. Each bug gets just one related stack trace.
Otherwise my head explodes.
-p
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Keywords: regression, topcrash
Resolution: --- → FIXED
Summary: RTM crash #4 - Mozilla crashes reproducible [@ il_find_in_cache] (ilclient.cpp, line : 396) → segfault @ nsCSSFrameConstructor::CantRenderReplacedElement
Status: RESOLVED → VERIFIED
Verified
You need to log in before you can comment on or make changes to this bug.