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)
Core
Graphics: ImageLib
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
Comment 3•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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
-----------------------------------------------------
Comment 9•24 years ago
|
||
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...
Reporter | ||
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
*** Bug 64517 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 65312 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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...
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
adding crash keywords and [@ il_find_in_cache] for tracking.
Comment 19•24 years ago
|
||
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?
Comment 20•24 years ago
|
||
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]
Comment 21•24 years ago
|
||
will this be automaticly fixed by including the new imagelib or should this be
nominated for the next milestone?
Comment 22•24 years ago
|
||
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
Comment 23•24 years ago
|
||
Moving all the image cache related topcrash bugs to me.
Assignee: pnunn → namachi
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 26•24 years ago
|
||
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
Updated•14 years ago
|
Crash Signature: [@ il_find_in_cache]
You need to log in
before you can comment on or make changes to this bug.
Description
•