Closed Bug 499948 Opened 15 years ago Closed 15 years ago

Crash on any download [@ nsAlertsIconListener::SendClosed]

Categories

(Toolkit :: UI Widgets, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 492211

People

(Reporter: gjunk, Unassigned)

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090622 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090622 Minefield/3.6a1pre

On any download - my standard test is downloading the nightly build - firefox crashes with a SEGV. Has been doing this for sometime.

The download always completes fine - the a notify window pops up on lower right advising the download has completed - waiting for this window to go away or clicking it away  - then the SEGV occurs.

Happens on a clean profile.


Reproducible: Always

Steps to Reproduce:
1.download firefox nightly build (or anything else)
2.wait till download completed notify window comes and then goes away
3. SEGV
Actual Results:  
Firefox crashes with a SEGV

Expected Results:  
not crashing ..

This is not https://bugzilla.mozilla.org/show_bug.cgi?id=438698 which seems to have been fixed - this crash is still happening.
works for me - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090623 Minefield/3.6a1pre

Anything useful in the dumps Shawn?
I don't actually know what to do with those dump files, so I hadn't looked yet.
I dont have debugging symbold in the build ... but if I run with -g and see where it crashes I get this:

Program received signal SIGSEGV, Segmentation fault.
0x06bf7c57 in ?? ()
   from /opt/Local/vers/mozilla/released/firefox-3.6a1pre-090622/components/libmozgnome.so
Missing separate debuginfos
without debugging symbols, it's pretty useless sadly.
you got a debuggable somewhere build i can run ?
It seems that we do not have builds with symbols that you can run :(
Apparently you can get the symbols with http://people.mozilla.com/~tmielczarek/fetch-symbols.py
Need a bit of help ... the python script above asks for:

<firefox install dir> <symbol server URL> <path to store in>

The install dir is mine - so im good - but what do I use for 
<symbol server URL>

and does it matter where the symbol info gets stored - the install dir or elsewhere ? 

What command do I give gdb to pick up the symbol info?

thanks .. happy to try help debug and get you a real backtrace.
The symbol server to use is http://symbols.mozilla.org/firefox

It shouldn't matter where you install it, but once you fire up gdb, you'll have to run |set debug-file-directory <path>| where <path> is the place you put them.
What do I use for <symbol server URL> ?
doh sorry .. you siad already .. thanks.
Here's what I got:

Program received signal SIGSEGV, Segmentation fault.
0x052bfc57 in ?? ()
   from /opt/shared/vers/mozilla/released/firefox-3.6a1pre-090617/components/libmozgnome.so

(gdb) bt
#0  0x052bfc57 in ?? ()
   from /opt/shared/vers/mozilla/released/firefox-3.6a1pre-090617/components/libmozgnome.so
#1  0x00000003 in ?? ()
#2  0x00000002 in ?? ()
#3  0x002f09c3 in g_type_check_value () from /lib/libgobject-2.0.so.0
#4  0x052bfebe in ?? ()
   from /opt/shared/vers/mozilla/released/firefox-3.6a1pre-090617/components/libmozgnome.so
#5  0x00000001 in ?? ()
#6  0xac6b2120 in ?? ()
#7  0x0000539f in ?? ()
#8  0x052bfea5 in ?? ()
   from /opt/shared/vers/mozilla/released/firefox-3.6a1pre-090617/components/libmozgnome.so
#9  0x0030b674 in g_datalist_clear () from /lib/libgobject-2.0.so.0
#10 0x052bfe98 in ?? ()
   from /opt/shared/vers/mozilla/released/firefox-3.6a1pre-090617/components/libmozgnome.so
#11 0xbfffdad8 in ?? ()
#12 0x002e161c in g_cclosure_marshal_VOID () from /lib/libgobject-2.0.so.0
Backtrace stopped: frame did not save the PC
here's a better stack, it has symbols.

(gdb) bt
#0  0x00000035c14a7f81 in nanosleep () from /lib64/libc.so.6
#1  0x00000035c14a7da7 in __sleep (seconds=<value optimized out>) at ../sysdeps/unix/sysv/linux/sleep.c:138
#2  0x00007ff183074e3c in ah_crap_handler (signum=11) at /home/db48x/moz/mozilla-central/toolkit/xre/nsSigHandlers.cpp:149
#3  0x00007ff183075e73 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:216
#4  <signal handler called>
#5  0x00007ff1777dbfa2 in nsCOMPtr<nsIObserver>::operator-> (this=0x41) at ../../../dist/include/nsCOMPtr.h:796
#6  0x00007ff1777da95a in nsAlertsIconListener::SendClosed (this=0x1) at /home/db48x/moz/mozilla-central/toolkit/system/gnome/nsAlertsIconListener.cpp:263
#7  0x00007ff1777db2e3 in notify_closed_cb (notification=0x7ff1569c67a0, user_data=0x1) at /home/db48x/moz/mozilla-central/toolkit/system/gnome/nsAlertsIconListener.cpp:66
#8  0x00000038ce20b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#9  0x00000038ce2214bd in ?? () from /lib64/libgobject-2.0.so.0
#10 0x00000038ce222b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#11 0x00000038ce223093 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#12 0x0000003213003929 in ?? () from /usr/lib64/libnotify.so.1
#13 0x00000038d6411994 in ?? () from /usr/lib64/libdbus-glib-1.so.2
#14 0x00000038ce20b7dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#15 0x00000038ce2214bd in ?? () from /lib64/libgobject-2.0.so.0
#16 0x00000038ce222b68 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#17 0x00000038ce223093 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#18 0x00000038d64129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2
#19 0x00000035c9c0ef7b in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#20 0x00000038d6409765 in ?? () from /usr/lib64/libdbus-glib-1.so.2
#21 0x00000038cde377bb in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#22 0x00000038cde3af8d in ?? () from /lib64/libglib-2.0.so.0
#23 0x00000038cde3b14b in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#24 0x00007ff1755fa26c in nsAppShell::ProcessNextNativeEvent (this=0x7ff16db2f710, mayWait=1) at /home/db48x/moz/mozilla-central/widget/src/gtk2/nsAppShell.cpp:147
#25 0x00007ff175622110 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x7ff16db2f710, mayWait=1) at /home/db48x/moz/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:151
#26 0x00007ff17562265a in nsBaseAppShell::OnProcessNextEvent (this=0x7ff16db2f710, thr=0x7ff181b27f20, mayWait=1, recursionDepth=0)
    at /home/db48x/moz/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:296
#27 0x00007ff1827bf506 in nsThread::ProcessNextEvent (this=0x7ff181b27f20, mayWait=1, result=0x7fff8b4ed75c) at /home/db48x/moz/mozilla-central/xpcom/threads/nsThread.cpp:497
#28 0x00007ff18274b6a2 in NS_ProcessNextEvent_P (thread=0x7ff181b27f20, mayWait=1) at nsThreadUtils.cpp:230
#29 0x00007ff175622878 in nsBaseAppShell::Run (this=0x7ff16db2f710) at /home/db48x/moz/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:170
#30 0x00007ff17ae925e0 in nsAppStartup::Run (this=0x7ff16db0fa60) at /home/db48x/moz/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:193
#31 0x00007ff1830659cf in XRE_main (argc=4, argv=0x7fff8b4ee138, aAppData=0x7ff181b0a080) at /home/db48x/moz/mozilla-central/toolkit/xre/nsAppRunner.cpp:3369
#32 0x0000000000401978 in main (argc=4, argv=0x7fff8b4ee138) at /home/db48x/moz/mozilla-central/browser/app/nsBrowserApp.cpp:156
Current language:  auto; currently c
(gdb) frame 5
#5  0x00007ff1777dbfa2 in nsCOMPtr<nsIObserver>::operator-> (this=0x41) at ../../../dist/include/nsCOMPtr.h:796
796               NS_PRECONDITION(mRawPtr != 0, "You can't dereference a NULL nsCOMPtr with operator->().");
Current language:  auto; currently c++
(gdb) up
#6  0x00007ff1777da95a in nsAlertsIconListener::SendClosed (this=0x1) at /home/db48x/moz/mozilla-central/toolkit/system/gnome/nsAlertsIconListener.cpp:263
263       mAlertListener->Observe(NULL, "alertfinished", mAlertCookie.get());
(gdb) p mAlertListener
Cannot access memory at address 0x1
(gdb) list
258     }
259
260     void
261     nsAlertsIconListener::SendClosed()
262     {
263       mAlertListener->Observe(NULL, "alertfinished", mAlertCookie.get());
264     }
265
266     nsresult
267     nsAlertsIconListener::InitAlertAsync(const nsAString & aImageUrl,
(gdb) q
Well, that crash makes sense.  nsAlertsIconListener is making the poor and unchecked assumption that we always pass in a listener.  This is, in fact, quite optional:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/public/nsIAlertsService.idl#77
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → critical
Component: General → Toolbars and Toolbar Customization
Keywords: crash
Product: Firefox → Toolkit
QA Contact: general → toolbars
Summary: Crash on any download → Crash on any download [@ nsAlertsIconListener::SendClosed]
Version: unspecified → Trunk
(In reply to comment #16)
> Well, that crash makes sense.  nsAlertsIconListener is making the poor and
> unchecked assumption that we always pass in a listener.  This is, in fact,
> quite optional:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/public/nsIAlertsService.idl#77

Indeed, but the obvious patch apparently just makes it crash elsewhere. The result is a fairly useless stack:

#0  0x00000035c14a7f81 in nanosleep () from /lib64/libc.so.6
#1  0x00000035c14a7da7 in __sleep (seconds=<value optimized out>) at ../sysdeps/unix/sysv/linux/sleep.c:138
#2  0x00007fcd746eae3c in ?? ()
#3  0x0000000000000000 in ?? ()
Current language:  auto; currently c
(gdb) q

Any ideas?
Ok, so a little debugging shows that in this case, the download manager is passing itself in as the listener, so nsAlertsIconListener::ShowAlert is passing itself as the user_data for the notification callback. The intent is for the callback function (notify_closed_cb) to use user_data to call SendClosed. However, when the callback is called, the value of the user_data is 0x1:

(gdb) p user_data
$4 = (gpointer) 0x1
(gdb) n
[Thread 0x7fffdd4fb950 (LWP 9299) exited]
65        nsAlertsIconListener* alert = static_cast<nsAlertsIconListener*> (user_data);
(gdb) p alert
$5 = (nsAlertsIconListener *) 0x38ce217ee0
(gdb) n
66        alert->SendClosed();
(gdb) p alert
$6 = (Cannot access memory at address 0x1

Obviously that'll crash eventually.
Well timeless doesn't make mistakes, so could someone explain in words or one syllable or less to this bear of little brain why this bug was moved to Toolbars and Toolbar Customization? Thanks.
Because there is no Toolkit::General that alert service bugs can go into?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
(In reply to comment #20)
> Because there is no Toolkit::General that alert service bugs can go into?

It doesn't make sense. It has nothing to do with Toolbar Customization. It's really more widget related as bug 492211 shows.
Component: Toolbars and Toolbar Customization → XUL Widgets
QA Contact: toolbars → xul.widgets
sdwilsh was right, i was moving it to the right product and picked something for lack of a general. people are welcome to find better components within the product.
Crash Signature: [@ nsAlertsIconListener::SendClosed]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: