Closed
Bug 59494
Opened 24 years ago
Closed 24 years ago
segfault @ nsCSSFrameConstructor::CantRenderReplacedElement
Categories
(Core :: Graphics: ImageLib, defect, P3)
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
Comment 1•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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.)
![]() |
||
Comment 12•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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
Comment 16•24 years ago
|
||
Bummer. That fixes other crashes.
Comment 17•24 years ago
|
||
The crash occurs on an image in the top frame: http://www.mobildiscount.de/images/bestellung.gif Talkback: TB20664575W
Comment 18•24 years ago
|
||
ahh and the sinner at itavisen.no is http://www.itavisen.no/ads/Stepstone1.gif
Comment 19•24 years ago
|
||
*** Bug 59510 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
http://www.penny-arcade.com/img/rspy.gif
Comment 21•24 years ago
|
||
-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.)
Reporter | ||
Comment 22•24 years ago
|
||
The 3 problematic pictures still crashes with the nightly from november the 8th.
Comment 23•24 years ago
|
||
*** Bug 59635 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
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.
Comment 26•24 years ago
|
||
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.
Comment 27•24 years ago
|
||
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.)
Assignee | ||
Comment 28•24 years ago
|
||
kaply: yep, would you back out the change to the minimum timer delay? I'll mention it in bug#55997. -p
Comment 29•24 years ago
|
||
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.
Assignee | ||
Comment 30•24 years ago
|
||
I think we are hitting some race conditions. Setting the timer to a minimum delay buys us a little time...so to speak. -p
Assignee | ||
Comment 31•24 years ago
|
||
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
Assignee | ||
Comment 32•24 years ago
|
||
*** Bug 61172 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 33•24 years ago
|
||
*** Bug 39310 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 34•24 years ago
|
||
*** Bug 58071 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
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]
Comment 36•24 years ago
|
||
couple 'o reloads of http://www.antena1.ro/ seem to get me crashed...
Comment 37•24 years ago
|
||
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] [@
Reporter | ||
Comment 38•24 years ago
|
||
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.
Assignee | ||
Comment 39•24 years ago
|
||
JU: Please don't confuse the issue. could you open a new bug? thanks.
Updated•24 years ago
|
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]
Reporter | ||
Comment 40•24 years ago
|
||
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
Comment 41•24 years ago
|
||
*** Bug 61931 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
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)
Assignee | ||
Comment 42•24 years ago
|
||
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
Assignee | ||
Comment 43•24 years ago
|
||
correction. 10000 loops....of one frame. -p
Assignee | ||
Comment 44•24 years ago
|
||
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
Reporter | ||
Comment 45•24 years ago
|
||
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...
Assignee | ||
Comment 46•24 years ago
|
||
maybe this on linux only? my pc tests were on nt. -p
Reporter | ||
Comment 47•24 years ago
|
||
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)
Reporter | ||
Comment 48•24 years ago
|
||
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
Assignee | ||
Comment 49•24 years ago
|
||
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
Assignee | ||
Comment 50•24 years ago
|
||
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
Updated•24 years ago
|
Status: RESOLVED → VERIFIED
Comment 51•24 years ago
|
||
Verified
You need to log in
before you can comment on or make changes to this bug.
Description
•