New crash [@nsAlertsIconListener::SendClosed()] in 3.6

RESOLVED FIXED in mozilla1.9.3a1

Status

()

defect
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: jst, Assigned: karlt)

Tracking

({crash, topcrash})

1.9.2 Branch
mozilla1.9.3a1
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -

Firefox Tracking Flags

(status1.9.2 beta5-fixed)

Details

(crash signature)

Attachments

(1 attachment)

Reporter

Description

10 years ago
There's a new crash with the signature nsAlertsIconListener::SendClosed() in 3.6 that we've never seen in 3.5. The stacks look mostly like this:

0  	libmozgnome.so  	nsAlertsIconListener::SendClosed  	 nsCOMPtr.h:777
1 	libmozgnome.so 	notify_closed_cb 	toolkit/system/gnome/nsAlertsIconListener.cpp:65
2 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x1661b 	
3 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x91fa 	
4 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x1f654 	
5 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x20d6b 	
6 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x211e5 	
7 	libnotify.so.1.1.2 	libnotify.so.1.1.2@0x2d38 	
8 	libnotify.so.1.1.2 	libnotify.so.1.1.2@0x5332 	
9 	libdbus-glib-1.so.2.1.0 	libdbus-glib-1.so.2.1.0@0xf42e 	
10 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x91fa 	
11 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x1f654 	
12 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x20d6b 	
13 	libgobject-2.0.so.0.1800.4 	libgobject-2.0.so.0.1800.4@0x211e5 	
14 	libdbus-glib-1.so.2.1.0 	libdbus-glib-1.so.2.1.0@0x10626 	
15 	libdbus-1.so.3.4.0 	libdbus-1.so.3.4.0@0xe174 	
16 	libdbus-glib-1.so.2.1.0 	libdbus-glib-1.so.2.1.0@0x708c 	
17 	libglib-2.0.so.0.1800.4 	libglib-2.0.so.0.1800.4@0x37257 	
18 	libglib-2.0.so.0.1800.4 	libglib-2.0.so.0.1800.4@0x3a902 	
19 	libglib-2.0.so.0.1800.4 	libglib-2.0.so.0.1800.4@0x3aac0 	
20 	libxul.so 	nsAppShell::ProcessNextNativeEvent 	widget/src/gtk2/nsAppShell.cpp:147
21 	libxul.so 	nsBaseAppShell::DoProcessNextNativeEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:151
22 	libxul.so 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:296
23 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:508
24 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:239
25 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
26 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:182
27 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3481
Reporter

Updated

10 years ago
Flags: blocking1.9.2?
Reporter

Updated

10 years ago
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 516124

Updated

10 years ago
Status: RESOLVED → VERIFIED
Flags: blocking1.9.2?
Reopening because bug 516124 is marked status-1.9.2:beta4-fixed, but this is still showing up in beta4.  e.g.
bp-655c34a3-1c3d-42ff-9205-3a26e2091129
bp-711e5718-56ea-4f9d-a3f4-3e9942091128
Blocks: 516124
Flags: blocking1.9.2?
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
This is the #5 topcrasher for b4 on Linux. It should probably block.

Bug 516124 fixed the problem of null observers, but it looks like these are just out-of-date observers. Michael/Karl, do you have any ideas off the top of your head as to what could cause this? Do we hold strong refs to our observers?

Has anybody run the observer mochitests through valgrind?
Keywords: topcrash
Whiteboard: [should block]
Duplicate of this bug: 496678
All the crashes with beta4 and recent trunk builds are on systems with Fedora
Core 10 kernels and all are with libnotify.so.1.1.2.

The older crash reported in bug 516124 comment 5 did not have an fc10 kernel and was in libnotify.so.1.1.3.  Also bp-a83917e3-61c4-412b-af7a-edc982091130 was with
a build prior to the fix for bug 516124, and did not have an fc10 kernel and was
with libnotify.so.1.1.3.

Bug 496678 reported that upgrading to Fedora 11 fixed the issue there.

Fedora 12 was released 2009-11-17.
http://fedoraproject.org/wiki/Releases/12/Schedule

So I'm expecting Fedora 10 end of life about 2009-12-17.
http://fedoraproject.org/wiki/LifeCycle
Fedora 10's libnotify-0.4.4-12.fc10 includes a local patch,
libnotify-closed-reason.patch
http://koji.fedoraproject.org/koji/rpminfo?rpmID=713287
which looks like it is
back-ported from this change in upstream development:
http://trac.galago-project.org/changeset/3005

This changed the signature of the "closed" signal on the NotifyNotification.
The break in the ABI was detected and corrected before libnotify-0.4.5
(http://trac.galago-project.org/changeset/3015)
but the correction didn't make it into Fedora 10.

What this means is that the "closed" handler function is being passed a
guint32 |reason| where it expects a gpointer (which is void*) user_data. 

So, we can expect this crash to only hurt users of an OS release that will end
of life very soon.  However, for these users, the app will crash every time
there is a notification.
This can be fixed by using g_signal_lookup() and g_signal_query() to inspect the signature of the callback function and registering a different callback for fc10.

FC10 users, using the Fedora-provided Firefox won't be experiencing this because they won't get the latest version.

The people suffering from this crash are most likely only those using our builds.
There are few of these users, though they are the users providing us with testing and feedback.  We can probably make an estimate of the number of such users from crash-stats.  21 crashes were reported in the last week for versions 3.6b4, 3.6b5pre, and 3.7a1pre (which makes this the top crash over all those versions on Linux).

Comment 9

10 years ago
(In reply to comment #6)
> All the crashes with beta4 and recent trunk builds are on systems with Fedora
> Core 10 kernels and all are with libnotify.so.1.1.2.

That's not correct IMHO ... https://bugzilla.redhat.com/show_bug.cgi?id=533029 and its numerous duplicates are on Fedora 12.

Comment 11

10 years ago
sorry, point taken
OK. In that case, we shouldn't block the release on that, though I would love to see a patch.
Whiteboard: [should block] → [should not block]

Updated

10 years ago
Flags: blocking1.9.2? → blocking1.9.2-
This is easier to workaround than described in comment 8.
This approach only needs about 3 extra code statements.
Assignee: nobody → karlt
Status: REOPENED → ASSIGNED
Attachment #415472 - Flags: review?(roc)
Attachment #415472 - Flags: approval1.9.2?
Attachment #415472 - Flags: approval1.9.2? → approval1.9.2+
http://hg.mozilla.org/mozilla-central/rev/4aad3da00bff
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Keywords: crash
Resolution: --- → FIXED
Whiteboard: [should not block] → [should not block][needs 192 landing]
Target Milestone: --- → mozilla1.9.3a1
Whiteboard: [should not block][needs 192 landing]
Crash Signature: [@nsAlertsIconListener::SendClosed()]
You need to log in before you can comment on or make changes to this bug.