109870 - browser crashes on all sites having no favicon including www.mozilla.org

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Favicon really seems to be the root of the problem : all crashes disappear when
the new pref is set to false...

Comment 2

[Hixie (not reading bugmail)]

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.)

Comment 3

[Boris Zbarsky [:bzbarsky]]

ccing hyatt who actually knows how this is supposed to work.

Comment 4

[Axel Hecht]

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)

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

cannot reproduce on win2k with fresh new build.

Comment 6

[James Green]

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

[Dawn Endico]

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)

Comment 8

[Axel Hecht]

I never removed those keywords on purpose, sorry

Comment 9

[Shannon Diener]

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

[Akkana Peck]

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.

Comment 11

[Mike Pinkerton (not reading bugmail)]

this crashes the OSX mach-o build as well in the same place.

Comment 12

[Mike Pinkerton (not reading bugmail)]

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

[James Green]

http://www.mirror.ac.uk/ does not appear to have a favicon, yet I don't crash
(same setup as above).

Comment 14

[Akkana Peck]

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

Comment 15

[Mike Pinkerton (not reading bugmail)]

setting

user_pref("browser.chrome.favicons", false);

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

Comment 16

[Håkan Waara]

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

Comment 17

[Daniel (Leaf) Nunes]

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

Comment 18

[David Hyatt]

--> me

Comment 19

[R.K.Aa.]

a linux cvs build with checkins up through 23:47 does not crash. I've been using
favicons since they were introduced.

Comment 20

[Brian Ryner (not reading)]

Attachment: patch

Comment 21

[David Hyatt]

sr=hyatt

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

r=dbaron, but jst should probably review this at some point (after it's checked
in, unless he reads email fast)

Comment 23

[Brian Ryner (not reading)]

checked in.

Comment 24

[Johnny Stenback (:jst)]

Oh, nice, duh! Yeah, nice catch, I don't even remember writing that, but that
was just stupid. Thanks for fixing it.

Comment 25

[Tracy Walker [:tracy]]

haven't crashed due to this in over a month