Bug 429179 - notification-daemon crashes when a notification is removed from the display
Summary: notification-daemon crashes when a notification is removed from the display
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: notification-daemon   
(Show other bugs)
Version: 5.1
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Matthias Clasen
QA Contact: desktop-bugs@redhat.com
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2008-01-17 19:28 UTC by John Dennis
Modified: 2008-05-21 17:27 UTC (History)
0 users

Fixed In Version: RHBA-2008-0414
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 17:27:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0414 normal SHIPPED_LIVE notification-daemon bug fix update 2008-05-19 22:35:01 UTC

Description John Dennis 2008-01-17 19:28:28 UTC
Description of problem:

When the notificaiton daemon removes a notification from the display the process
receives an abort signal and exits. The early exit prevents NotificationClosed
signals from being emitted on DBUS which means the gtk2 widget never emits it's
close signal. This confuses the application which created the notification and
tricks it into believing the notification is still visible when it isn't. This
causes the application to fail to show ever show the notification again because
it mistakenly believes the notification is visible. If the application didn't
connect to the close signal it would put up multiple notifications, an equally
bad behavior.

The crashing of notification-daemon is pernicous because it is automatically
restarted by DBUS for the next notification display, thus it's constant abnormal
exits are masked and leaves things in an inconsistent state.

Version-Release number of selected component (if applicable):

How reproducible: 100%

Steps to Reproduce:

% notify-send -t 1000000 foo bar
% ps ax | grep notification-daemon
 9227 ?        S      0:00 /usr/libexec/notification-daemon
% gdb program 9227

click on the notification to close it, watch it abort in gdb

Actual results:
daemon dies without cleanup

Expected results:
daemon lives, continues to receive/send dbus messages

Additional info:

Below is the stack trace. It is generated after theme_hide_notification() in
engines.c is called. The abort is triggered because of:
 gtkstyle.c:783  g_return_if_fail (style->attach_count > 0) which is 0.

Program received signal SIGABRT, Aborted.
[Switching to Thread -1208092464 (LWP 9059)]
0x00b8c402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00b8c402 in __kernel_vsyscall ()
#1  0x0069dc50 in raise () from /lib/libc.so.6
#2  0x0069f561 in abort () from /lib/libc.so.6
#3  0x0060ac92 in g_logv () from /lib/libglib-2.0.so.0
#4  0x0060acc9 in g_log () from /lib/libglib-2.0.so.0
#5  0x0060adab in g_return_if_fail_warning () from /lib/libglib-2.0.so.0
#6  0x002b2b92 in IA__gtk_style_detach (style=0x938a170) at gtkstyle.c:783
#7  0x0035f671 in gtk_widget_real_unrealize (widget=0x9389800)
    at gtkwidget.c:7040
#8  0x0036a1e3 in gtk_window_unrealize (widget=0x9389800) at gtkwindow.c:4425
#9  0x005aa259 in g_cclosure_marshal_VOID__VOID ()
   from /lib/libgobject-2.0.so.0
#10 0x0059b6f9 in g_value_set_static_boxed () from /lib/libgobject-2.0.so.0
#11 0x0059cf0b in g_closure_invoke () from /lib/libgobject-2.0.so.0
#12 0x005ae4d3 in g_signal_override_class_closure ()
   from /lib/libgobject-2.0.so.0
#13 0x005af37f in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#14 0x005af539 in g_signal_emit () from /lib/libgobject-2.0.so.0
#15 0x0035ae62 in IA__gtk_widget_unrealize (widget=0x9389800)
    at gtkwidget.c:2550
#16 0x0035b805 in gtk_widget_dispose (object=0x9389800) at gtkwidget.c:6883
#17 0x00367ad6 in gtk_window_dispose (object=0x9389800) at gtkwindow.c:1794
#18 0x0059f1ab in g_object_unref () from /lib/libgobject-2.0.so.0
#19 0x002393b3 in IA__gtk_propagate_event (widget=0x9389800, event=0x9380410)
    at gtkmain.c:2191
#20 0x0023a6a7 in IA__gtk_main_do_event (event=0x9380410) at gtkmain.c:1422
#21 0x008e32aa in gdk_event_dispatch (source=0x93742a8, callback=0, 
    user_data=0x0) at gdkevents-x11.c:2320
#22 0x00602342 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#23 0x0060531f in g_main_context_check () from /lib/libglib-2.0.so.0
#24 0x006056c9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#25 0x0023ab24 in IA__gtk_main () at gtkmain.c:1001
#26 0x0804c6f7 in main (argc=11259375, argv=0xabcdef) at daemon.c:1107
#27 0x0068adec in __libc_start_main () from /lib/libc.so.6
#28 0x0804a0e1 in _start ()
(gdb) up
#1  0x0069dc50 in raise () from /lib/libc.so.6
(gdb) up
#2  0x0069f561 in abort () from /lib/libc.so.6
(gdb) up
#3  0x0060ac92 in g_logv () from /lib/libglib-2.0.so.0
#4  0x0060acc9 in g_log () from /lib/libglib-2.0.so.0
#5  0x0060adab in g_return_if_fail_warning () from /lib/libglib-2.0.so.0
#6  0x002b2b92 in IA__gtk_style_detach (style=0x938a170) at gtkstyle.c:783
783       g_return_if_fail (style->attach_count > 0);
(gdb) p style->attach_count
$1 = 0

Comment 2 John Dennis 2008-01-18 15:26:05 UTC
I think I may have found the fix for this known bug, it seems to be detailed here:


I will try patching the RHEL 5 version and see if we've got a fix.

Comment 3 Matthias Clasen 2008-01-18 16:37:58 UTC
Thanks for the dectective work, John.

Not sure about the necessary flagwork here, but I set dev-ack+, based on this
very simple patch. I'll build a patched package once the necessary flags are 

Comment 5 John Dennis 2008-01-18 16:48:31 UTC
Well, we're not out of the woods yet :-) The patch solves the abort, but the
NotificationClosed signal does not seem to be emitted on the session bus, it's
that signal which was crucial to fixing the application behavior.

Comment 6 RHEL Product and Program Management 2008-01-18 16:56:32 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 13 errata-xmlrpc 2008-05-21 17:27:03 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.