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
Dupe of bug 516124?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 516124
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
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?
Whiteboard: [should block]
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).
(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.
Matej, https://bugzilla.redhat.com/show_bug.cgi?id=533029 is related to already fixed bug 516124.
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]
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: review?(roc) → review+
Attachment #415472 - Flags: approval1.9.2?
Attachment #415472 - Flags: approval1.9.2? → approval1.9.2+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
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.