Closed
Bug 499948
Opened 15 years ago
Closed 15 years ago
Crash on any download [@ nsAlertsIconListener::SendClosed]
Categories
(Toolkit :: UI Widgets, defect)
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.
For crash dumps from a clean profile - see https://bugzilla.mozilla.org/show_bug.cgi?id=438698#c10 https://bugzilla.mozilla.org/show_bug.cgi?id=438698#c11
Comment 3•15 years ago
|
||
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?
Comment 4•15 years ago
|
||
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
Comment 6•15 years ago
|
||
without debugging symbols, it's pretty useless sadly.
Comment 8•15 years ago
|
||
It seems that we do not have builds with symbols that you can run :(
Comment 9•15 years ago
|
||
Apparently you can get the symbols with http://people.mozilla.com/~tmielczarek/fetch-symbols.py
Reporter | ||
Comment 10•15 years ago
|
||
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.
Comment 11•15 years ago
|
||
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.
Reporter | ||
Comment 12•15 years ago
|
||
What do I use for <symbol server URL> ?
Reporter | ||
Comment 13•15 years ago
|
||
doh sorry .. you siad already .. thanks.
Reporter | ||
Comment 14•15 years ago
|
||
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
Comment 15•15 years ago
|
||
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
Comment 16•15 years ago
|
||
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
Comment 17•15 years ago
|
||
(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?
Comment 18•15 years ago
|
||
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.
Comment 19•15 years ago
|
||
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.
Comment 20•15 years ago
|
||
Because there is no Toolkit::General that alert service bugs can go into?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Comment 22•15 years ago
|
||
(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
Comment 23•15 years ago
|
||
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.
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsAlertsIconListener::SendClosed]
You need to log in
before you can comment on or make changes to this bug.
Description
•