Linux RedHat7.1 build 20011106 20 minutes old (so after last David's check-in); built from fresh tree. Mozilla crashes on all web sites having no favicon, including www.mozilla.org, and works fine on sites having a favicon... Stack trace: #0 0x400dfd07 in js_strlen (s=0x1) at jsstr.c:2636 #1 0x400df41e in js_NewStringCopyZ (cx=0x8333f08, s=0x1, gcflag=0) at jsstr.c:2486 #2 0x4006113c in JS_NewUCStringCopyZ (cx=0x8333f08, s=0x1) at jsapi.c:3544 #3 0x4005791e in JS_PushArgumentsVA (cx=0x8333f08, markp=0xbfffec0c, format=0x41a8347a "Wi", ap=0xbfffead0) at jsapi.c:327 #4 0x4005763a in JS_PushArguments (cx=0x8333f08, markp=0xbfffec0c, format=0x41a83479 "WWi") at jsapi.c:264 #5 0x41a539bf in nsJSEventListener::HandleEvent (this=0x83ec3a0, aEvent=0x41880224) at nsJSEventListener.cpp:155 #6 0x414ce981 in nsEventListenerManager::HandleEventSubType (this=0x83ec1f0, aListenerStruct=0x83ec438, aDOMEvent=0x41880224, aCurrentTarget=0x83ec1b8, aSubType=8, aPhaseFlags=7) at nsEventListenerManager.cpp:1213 #7 0x414d106f in nsEventListenerManager::HandleEvent (this=0x83ec1f0, aPresContext=0x8285638, aEvent=0xbffff280, aDOMEvent=0xbffff21c, aCurrentTarget=0x83ec1b8, aFlags=7, aEventStatus=0xbffff2b8) at nsEventListenerManager.cpp:1886 #8 0x415f068e in nsXULElement::HandleDOMEvent (this=0x83ec1b0, aPresContext=0x8285638, aEvent=0xbffff280, aDOMEvent=0xbffff21c, aFlags=1, aEventStatus=0xbffff2b8) at nsXULElement.cpp:3401 #9 0x42179154 in HandleImagePLEvent (aContent=0x83ec1b0, aMessage=1104, aFlags=1) at nsImageBoxFrame.cpp:143 #10 0x4217924a in HandleImageOnerrorPLEvent (aEvent=0x8709048) at nsImageBoxFrame.cpp:162 #11 0x401dc54c in PL_HandleEvent (self=0x8709048) at plevent.c:590 #12 0x401dc361 in PL_ProcessPendingEvents (self=0x8090948) at plevent.c:520 #13 0x401de592 in nsEventQueueImpl::ProcessPendingEvents (this=0x8090920) at nsEventQueue.cpp:388 #14 0x409a74d4 in event_processor_callback (data=0x8090920, source=6, condition=GDK_INPUT_READ) at nsAppShell.cpp:184 #15 0x409a70b3 in our_gdk_io_invoke (source=0x8286b78, condition=G_IO_IN, data=0x8225b98) at nsAppShell.cpp:77 #16 0x4048601e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #17 0x404877f3 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #18 0x40487dd9 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #19 0x40487f8c in g_main_run () from /usr/lib/libglib-1.2.so.0 #20 0x4039c803 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #21 0x409a7b49 in nsAppShell::Run (this=0x809e698) at nsAppShell.cpp:364 #22 0x4094993d in nsAppShellService::Run (this=0x80940f0) at nsAppShellService.cpp:302 #23 0x08058c71 in main1 (argc=1, argv=0xbffff73c, nativeApp=0x0) at nsAppRunner.cpp:1304 #24 0x0805992f in main (argc=1, argv=0xbffff73c) at nsAppRunner.cpp:1630 #25 0x405d2177 in __libc_start_main (main=0x8059728 <main>, argc=1, ubp_av=0xbffff73c, init=0x8053460 <_init>, fini=0x8061850 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff72c) at ../sysdeps/generic/libc-start.c:129
Favicon really seems to be the root of the problem : all crashes disappear when the new pref is set to false...
Given the stack trace, I highly doubt that the problem is in favicon code, although of course it might well be triggered by it. Sending to JS Engine, although the problem could be that the string sent to the JS engine is in some way corrupted, in which case it is probably a DOM error. (I guess it could also be that the event generated is in some way sending an invalid string, although in that case we'll need to find out what event it is and whether the DOM code should handle the error instead of crashing.)
ccing hyatt who actually knows how this is supposed to work.
I can't reproduce this on my solaris debug build. Maybe this is timing related? (I work on a remote X display, so I'm generally way low in performance)
cannot reproduce on win2k with fresh new build.
Unable to reproduce on Linux, built with gcc-3.0.2, pulled from tip sometime between jag's last changes and 0700PST, so I definitely have hyatt's checkin.
um, nice timing. I just added <link REL="icon" HREF="images/mozilla-16.png" TYPE="image/png"> to www.mozilla.org so using www.mozilla.org as a test case probably won't work. (http://mozilla.org/favicon.ico still doesn't exist)
I never removed those keywords on purpose, sorry
I'm seeing this on HP-UX ... a build from this morning around 8. My stack trace also looks similar to the one posted.
I'm seeing this, too, with a new profile (had to remove .mozilla due to another bug). I just filed another bug on it, which I'll dup to this one.
this crashes the OSX mach-o build as well in the same place.
what is actually causing the crash is that calling va_arg with a format of 'W' creates a bogus string (address 0x2), which strlen barfs on.
http://www.mirror.ac.uk/ does not appear to have a favicon, yet I don't crash (same setup as above).
*** Bug 109958 has been marked as a duplicate of this bug. ***
setting user_pref("browser.chrome.favicons", false); fixes this. can we just turn off this "feature?"
I'm in favor for turning it off. This bug doesn't even have an engineer working on it.
r=leaf for turning off the pref while this gets fixed.
a linux cvs build with checkins up through 23:47 does not crash. I've been using favicons since they were introduced.
r=dbaron, but jst should probably review this at some point (after it's checked in, unless he reads email fast)
Oh, nice, duh! Yeah, nice catch, I don't even remember writing that, but that was just stupid. Thanks for fixing it.
haven't crashed due to this in over a month