Closed
Bug 530921
Opened 16 years ago
Closed 16 years ago
New crash [@nsAlertsIconListener::SendClosed()] in 3.6
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta5-fixed |
People
(Reporter: jst, Assigned: karlt)
References
Details
(Keywords: crash, topcrash)
Crash Data
Attachments
(1 file)
2.64 KB,
patch
|
roc
:
review+
roc
:
approval1.9.2+
|
Details | Diff | Splinter Review |
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
Comment 1•16 years ago
|
||
Dupe of bug 516124?
Reporter | ||
Updated•16 years ago
|
Flags: blocking1.9.2?
Reporter | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Updated•16 years ago
|
Flags: blocking1.9.2?
Assignee | ||
Comment 3•16 years ago
|
||
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?
Assignee | ||
Updated•16 years ago
|
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Comment 4•16 years ago
|
||
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]
Assignee | ||
Comment 6•16 years ago
|
||
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
Assignee | ||
Comment 7•16 years ago
|
||
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.
Assignee | ||
Comment 8•16 years ago
|
||
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•16 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 10•16 years ago
|
||
Matej, https://bugzilla.redhat.com/show_bug.cgi?id=533029 is related to already fixed bug 516124.
Comment 11•16 years ago
|
||
sorry, point taken
Comment 12•16 years ago
|
||
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•16 years ago
|
Flags: blocking1.9.2? → blocking1.9.2-
Assignee | ||
Comment 13•16 years ago
|
||
This is easier to workaround than described in comment 8.
This approach only needs about 3 extra code statements.
Attachment #415472 -
Flags: review?(roc) → review+
Assignee | ||
Updated•16 years ago
|
Attachment #415472 -
Flags: approval1.9.2?
Attachment #415472 -
Flags: approval1.9.2? → approval1.9.2+
Assignee | ||
Comment 14•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Keywords: crash
Resolution: --- → FIXED
Whiteboard: [should not block] → [should not block][needs 192 landing]
Target Milestone: --- → mozilla1.9.3a1
Assignee | ||
Comment 15•16 years ago
|
||
status1.9.2:
--- → final-fixed
Assignee | ||
Updated•16 years ago
|
Whiteboard: [should not block][needs 192 landing]
Updated•14 years ago
|
Crash Signature: [@nsAlertsIconListener::SendClosed()]
You need to log in
before you can comment on or make changes to this bug.
Description
•