Closed Bug 62966 Opened 24 years ago Closed 24 years ago

N601 crash #6 - stack: il_find_in_cache [@ il_find_in_cache]

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: pnunn, Assigned: pavlov)

References

()

Details

(Keywords: crash, topcrash)

Crash Data

------- Additional Comments From jpatel@netscape.com 2000-11-29 11:38 ------- 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 ------- Additional Comments From chris hofmann 2000-11-30 18:14 ------- couple 'o reloads of http://www.antena1.ro/ seem to get me crashed... ------- Additional Comments From namachi@netscape.com 2000-12-04 14:30 ------- 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 ------- Additional Comments From Jens-Uwe 2000-12-05 03:09 ------- 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. ------- Additional Comments From pnunn@netscape.com 2000-12-05 11:01 ------- JU: Please don't confuse the issue. could you open a new bug? thanks. ------- Additional Comments From Jens-Uwe 2000-12-06 02:59 ------- 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 ------- Additional Comments From Asa Dotzler 2000-12-06 18:37 ------- *** Bug 61931 has been marked as a duplicate of this bug. *** ------- Additional Comments From pnunn@netscape.com 2000-12-13 15:39 ------- 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 ------- Additional Comments From pnunn@netscape.com 2000-12-13 15:40 ------- correction. 10000 loops....of one frame. -p ------- Additional Comments From pnunn@netscape.com 2000-12-13 15:50 ------- 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 ------- Additional Comments From Jens-Uwe 2000-12-14 03:26 ------- 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... ------- Additional Comments From pnunn@netscape.com 2000-12-14 10:56 ------- maybe this on linux only? my pc tests were on nt. -p ------- Additional Comments From Jens-Uwe 2000-12-14 11:24 ------- 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) ------- Additional Comments From Jens-Uwe 2000-12-14 11:25 ------- 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 ------- Additional Comments From pnunn@netscape.com 2000-12-14 11:42 ------- 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>. This bug was created from the mess of comments in bug#59494. This bug should only cover the RTM #4 crash problem involving the stack trace beginning with "il_find_in_cache".
Status: NEW → ASSIGNED
crash related to http://clubs.yahoo.com/clubs/israelishoppingclub with a stacktrace of "il_delete_container()" has been moved to bug# 62973. This bug occurs in moz builds. Please. Please don't add info relating to that bug to this bug which only deals with the RTM#4 bug with a stack trace of "il_find_in_cache()". -p
This is also the #6 topcrasher for the RTM release on Linux (and a topcrasher for Mac). Here are some URLs and Comments from Linux users: URL:(23132816) www.delfi.lv Comment: (23132816) reading this page URL:(23161087) www.a2zbollywood.com Comment: (23161087) Scrolling down the page URL:(23179018) http://www.elpais.es Comment: (23179018) Just browsing around URL:(23123866) ftp://ftp.netscape.com Comment: (23173764) was browsing (the WWW)
OS: Windows NT → All
jpatel: Did all of these urls crash with the same crash stack. Was that crash stack "il_find_in_cache"? -p
pnunn - yes, all the urls and comments i added today were from reports that showed the same stack trace. The top 50 lines of the stack were identical... Here is the stack trace from one of the reports (the others are pretty much the same): Incident ID 23179018 il_find_in_cache() il_get_container() IL_GetImage() ImageRequestImpl::Init() ImageGroupImpl::GetImage() nsFrameImageLoader::Init() nsPresContext::StartLoadImage() nsHTMLImageLoader::StartLoadImage() nsHTMLImageLoader::UpdateURLSpec() nsImageBoxFrame::UpdateImage() nsImageBoxFrame::DidSetStyleContext() nsFrame::SetStyleContext() FrameManager::ReResolveStyleContext() FrameManager::ReResolveStyleContext() FrameManager::ReResolveStyleContext() FrameManager::ComputeStyleChangeFor() nsCSSFrameConstructor::AttributeChanged() StyleSetImpl::AttributeChanged() PresShell::AttributeChanged() librdf.so + 0x601a5 (0x4086f1a5) librdf.so + 0x50215 (0x4085f215) librdf.so + 0x4cbd3 (0x4085bbd3) ElementSetAttribute() js_Invoke() js_Interpret() js_Invoke() libxpconnect.so + 0x2bfca (0x40795fca) libxpconnect.so + 0x2a951 (0x40794951) PrepareAndDispatch() nsXPTCStubBase::Stub7() nsBrowserInstance::OnStateChange() nsDocLoaderImpl::FireOnStateChange() nsDocLoaderImpl::doStartDocumentLoad() nsDocLoaderImpl::OnStartRequest() nsLoadGroup::AddChannel() nsHTTPChannel::Open() nsHTTPChannel::AsyncRead() nsDocumentOpenInfo::Open() nsURILoader::OpenURIVia() nsURILoader::OpenURI() nsDocShell::DoChannelLoad() nsDocShell::DoURILoad() nsDocShell::InternalLoad() nsWebShell::HandleLinkClickEvent() HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xf340 (0x4066f340) libglib-1.2.so.0 + 0x10bd6 (0x40670bd6) libglib-1.2.so.0 + 0x11203 (0x40671203) libglib-1.2.so.0 + 0x113cc (0x406713cc) libgtk-1.2.so.0 + 0x9300c (0x4059000c) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x18a4e (0x4026aa4e)
*** Bug 60038 has been marked as a duplicate of this bug. ***
Summary: RTM crash #4 - Mozilla crashes reproducible [@ il_find_in_cache] (ilclient.cpp, line : 396) → RTM crash #4 - stack: il_find_in_cache
I'm having trouble getting a crash on these today, but I did see them yesterday. Here is some of the info I've gathered. Many many of the urls listed have a link to a 1x1 tracking image. I'll list the image urls and list the sites with the tracking images below. On the sites that do not have the tracking image, there is usually an odd gif that ...seems odd. Like a 0x0 gif. Now if I could just get it to crash in the debugger..... -------------------------------------------------------------------------------- --------- 1x1 Tracking Image URLs: -------------------------------------------------------------------------------- --------- http://www.commission-junction.com/banners/tracker.exe?AID=54578&PID=542239&bann er=0.gif http://www.commission-junction.com/banners/tracker.exe?AID=314342&PID=542239&ban ner=0.gif http://www.commission-junction.com/banners/tracker.exe?AID=518248&PID=542239&ban ner=0.gif http://t0.extreme-dm.com/0.gif?tag=austweb&j=n http://t0.extreme-dm.com/ http://u0.extreme-dm.com/0.gif?tag=lvdelfi&j=y&srw=1280&srb=24&rs=41&i= http://visit.geocities.com/visit.gif http://y0.extreme-dm.com/i/ http://y.extreme-dm.com/s?tag=antixx http://y1.extreme-dm.com/z/?tag=avontuur&j=y&swr=1280&srb=24&rs=41&l=http%3A//bu gzilla.mozilla.org/show http://psoup.math.wisc.edu/cgi-bin/griffeat_makelog.pl?Primordial=Soup=Kitchen,h ttp://psoup.math.wisc.edu/kitchen.html http://www.top.lv.counter.phtml?id=615&nid=4&ref= http://stats.superstats.com/b.cgi?u=hmv_40975&z=1&n=6ses47307957&fg=2&r=&s=1280x 1024& http://images.freshmeat.net/FreshMeat/Core/pc.igf?/index.php3,977362102132 ----------------------------------------------------- -------------------------------------------------------------------------------- --------- matching url sites with 1x1 trackers: -------------------------------------------------------------------------------- --------- www.delfi.lv http://u0.extreme-dm.com/0.gif?tag=lvdelfi&j=y&srw=1280&srb=24&rs=41&i= www.a2zbollywood.com http://stats.superstats.com/b.cgi?u=hmv_40975&z=1&n=6ses47307957&fg=2&r=&s=1280x 1024&c=24&o=Linux%202.2.14-5.0smp%20i686& www.stack.nl/~brama/mp3blaster.html http://y1.extreme-dm.com/z/?tag=avontuur&j=y&swr=1280&srb=24&rs=41&l=http%3A//bu gzilla.mozilla.org/show www.freshmeat.net http://images.freshmeat.net/FreshMeat/Core/pc.igf?/index.php3,977362102132 www.chetbrzezinski.com http://u.extreme-dm.com/?login=cbrzezin http://212.72.46.18/open;sum?login=cbrzezin www.geocities.com/Heartland/Park/8172/ http://extreme-cm.com/z/?tag=lecoyote&j=y&srw=1280&srb24&l=http%3A//bugzilla.moz illa.org http://visit.geocities.com/visit.gif?&r=http%3A//bugzilla.mozilla.org/sho_bug.cg i%3D62966&b= www.sabetv.com no evil 1x1's but one 0x0 gif. "a.gif" www.zakzak.co.jp no evil 1x1's but 2 'not found' images. http://www.zakzak.co.jp/images/netnow3.gif /ie_animated.gif -----------------------------------------------------
*** Bug 63777 has been marked as a duplicate of this bug. ***
I've had absolutely zero luck reproducing this on MacOS 9.1 running on a 300MHz G3 laptop. Going to swtich to linux now since most of the comments seem to be from linux users...
Chris: take a look at bug#63750. It looks to me like the FrameImageLoader is destroying the image just before its needed to draw. Perhaps the 1x1 tracker bug is another variation of the same problem problem. Try a breaks in breaks in : IL_DestroyImage(), mozilla/modules/libimg/src/ilclient.cpp IL_GetImage(), mozilla/modules/libimg/src/if.cpp to monitor the cycle of creation/destruction. -p
*** Bug 64517 has been marked as a duplicate of this bug. ***
*** Bug 65312 has been marked as a duplicate of this bug. ***
This is really annoying crash. I often visit the http://www.amdzone.com/ and I have to stop the loading before all images on the page load otherwise the mozilla would crash. I'm seeing it for very long time. Someone with the privilege please set the crash keyword on this bug.
tom: are you sure, that you are talking about the same bug? I never had problems with amdzone, and I visit amdzone daily (linux, Java disabled). Can you please make a stack trace and check, if this is really the same problem? I guess that with the topic "RTM crash #4" there is no need for adding a new keyword.
Hmm... I just don't know if it's the same problem - I'm unable to debug mozilla nightlies. I'm running RH Linux 7.0 with all recent updates. And mozilla crashes on most of the URLs listed here. I have now Linux nightly 2001011621 with Java from NS6.0 installed.
tom: starting mozilla with "./mozilla -g" starts it with a debugger (ddd or gdb). When mozilla crashed, it will show some informations, and when you enter "where", it gives you even more :-) with these informations one usually have atleast some idea of where the crash happened. if it is in il_find_in_cache, it is this bug, otherwise its probably something different...
I know that ./mozilla -g starts mozilla with debugger but it doesn't work for me for long time. I don't know what's the cause. Additional information - I'm using the -sea.tar.gz builds, maybe that's the reason.
adding crash keywords and [@ il_find_in_cache] for tracking.
Keywords: crash, topcrash
Summary: RTM crash #4 - stack: il_find_in_cache → RTM crash #4 - stack: il_find_in_cache [@ il_find_in_cache]
tom: I can now also reproduce the bug at AMDZone.com. It is not in il_find_in_cache but in ImgDCallbk::CreateInstance. Therefore I created a new bug (bug 66656). It is strange, that I was not able to reproduce your bug, but today it crashes mozilla each and every time. In my comment from 2000-12-14 11:25 in this bug here I also had a crash in ImgDCallbk::CreateInstance, perhaps this is related?
changing summary to N601. this is still a topcrasher with N601 builds. the stack trace still looks the same. here are some more urls given by users: URL:(26575367) hitboss.com URL:(26182078) http://www.amdzone.com URL:(26388179) www.subtle.homestead.com/words.html URL:(26114919) http://www.once-upon-a-forest/ URL:(26433914) http://www.heebie.net/royo/royo4.htm URL:(26248879) http://www.icq.com/sms/smsnetworks.html URL:(26434466) www.lcsi.ca/ URL:(26349967) http://www.dreamless.org/ubb/Forum2/HTML/001268.html URL:(26173806) www.hwupgrade.com URL:(26351549) www.sinsations.com URL:(26538901) http://www.sci.fi/~tomcat14/tv.html URL:(26554184) www.danmansmusic.com URL:(26514452) http://www.execsoft-europe.com/ URL:(26124591) www.di.ca URL:(26458595) www.webberville.com URL:(26429419) http://mail.myrealbox.com/webmail URL:(26573275) www.earocha77.homestead.com/darkdynasty.html URL:(26514609) www.homestead.com URL:(26349565) www.xaviersite.com URL:(26433866) www.lcsi.ca/ URL:(26549558) www.kournikovasite.org URL:(26529746) www.sfzoo.com URL:(26355090) www.infozoid.com URL:(26243730) http://www.gamewallpapers.com/ URL:(26397619) http://stormgunky.homestead.com/ URL:(26145142) http://elvissongfavorites.homestead.com/ URL:(26145164) www.codecenter.com URL:(26483729) tweak3d.net URL:(26494650) www.cyberage.com URL:(26335359) www.netscape.com URL:(26525171) www.topmen.homestead.com URL:(26431848) www.canalplus.fr
Summary: RTM crash #4 - stack: il_find_in_cache [@ il_find_in_cache] → N601 crash #6 - stack: il_find_in_cache [@ il_find_in_cache]
will this be automaticly fixed by including the new imagelib or should this be nominated for the next milestone?
I just tried all the mentioned pages. Some could not found any more, some seemed to load forever, but none crashed my Mozilla. I am using 2001021821 for Linux
Moving all the image cache related topcrash bugs to me.
Assignee: pnunn → namachi
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla0.9
Depends on: 70938
Using nscatfood keyword to track crash car bugs.
Keywords: nsCatFood
taking
Assignee: namachi → pavlov
the code in this bug is no longer used as the new image library is on everywhere.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified
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.