browser crashes on all sites having no favicon including



16 years ago
13 years ago


(Reporter: glazou, Assigned: David Hyatt)


({crash, regression, smoketest})

crash, regression, smoketest

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
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,
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/
#17 0x404877f3 in g_main_dispatch () from /usr/lib/
#18 0x40487dd9 in g_main_iterate () from /usr/lib/
#19 0x40487f8c in g_main_run () from /usr/lib/
#20 0x4039c803 in gtk_main () from /usr/lib/
#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


16 years ago
Keywords: regression, smoketest

Comment 1

16 years ago
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.)
Assignee: hyatt → rogerl
Component: Browser-General → Javascript Engine
QA Contact: doronr → pschwartau
ccing hyatt who actually knows how this is supposed to work.

Comment 4

16 years ago
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)
Component: Javascript Engine → Browser-General
Keywords: regression, smoketest
QA Contact: pschwartau → doronr

Comment 5

16 years ago
cannot reproduce on win2k with fresh new build.

Comment 6

16 years ago
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.

Comment 7

16 years ago
um, nice timing. I just added 
<link REL="icon" HREF="images/mozilla-16.png" TYPE="image/png">
to so using as a test case probably won't
work. ( still doesn't exist)

Comment 8

16 years ago
I never removed those keywords on purpose, sorry
Keywords: regression, smoketest

Comment 9

16 years ago
I'm seeing this on HP-UX ... a build from this morning around 8.  My stack trace
also looks similar to the one posted.

Comment 10

16 years ago
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.

Comment 13

16 years ago does not appear to have a favicon, yet I don't crash
(same setup as above).
Keywords: crash

Comment 14

16 years ago
*** Bug 109958 has been marked as a duplicate of this bug. ***

user_pref("", false);

fixes this. can we just turn off this "feature?"

Comment 16

16 years ago
I'm in favor for turning it off. This bug doesn't even have an engineer working 
on it.

Comment 17

16 years ago
r=leaf for turning off the pref while this gets fixed.

Comment 18

16 years ago
--> me
Assignee: rogerl → hyatt


16 years ago
Target Milestone: --- → mozilla0.9.7

Comment 19

16 years ago
a linux cvs build with checkins up through 23:47 does not crash. I've been using
favicons since they were introduced.
Target Milestone: mozilla0.9.7 → ---
Created attachment 57662 [details] [diff] [review]

Comment 21

16 years ago
r=dbaron, but jst should probably review this at some point (after it's checked
in, unless he reads email fast)
checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.