Bug 1173716

Created attachment 967788 [details]
File: backtrace

Created attachment 967789 [details]
File: core_backtrace

Created attachment 967790 [details]
File: dso_list

Created attachment 967791 [details]
File: environ

Created attachment 967792 [details]
File: maps

Created attachment 967793 [details]
File: proc_pid_status

Created attachment 967794 [details]
File: var_log_messages

I upgraded to Fedora 21 today and have the same issue, in an LXDE/openbox environment however. It is easily reproduced (thus creating a core file), I do not have enough knowledge of gdb however to debug.

Bug 1174400 seems to be a duplicate.

There does not seem to be a lot of activity involved in this bug report. Hope this will get some attention soon.

Been doing some more testing, the notification-daemon does not crash right away but seems to be crashing either on mouseover or appearance timeout. Hope this helps in any way tracking down the culprit.

Did some more debugging:

(gdb) bt
#0  g_logv (log_domain=0x3bb54b644e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffc90ca460)
    at gmessages.c:1046
#1  0x0000003bb5450e9f in g_log (log_domain=log_domain@entry=0x3bb54b644e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
    format=format@entry=0x3bb54bda18 "Source ID %u was not found when attempting to remove it") at gmessages.c:1079
#2  0x0000003bb54488fc in g_source_remove (tag=18) at gmain.c:2241
#3  0x000000000040831c in add_timeout (bubble=0x1898400) at nd-bubble.c:399
#4  0x000000000040965c in nd_bubble_leave_notify_event (widget=0x1898400, event=<optimized out>) at nd-bubble.c:434
#5  0x0000003f899ed65e in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x15d2de0, return_value=0x7fffc90ca6d0, instance=<optimized out>,
    args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x15d2e10) at gtkmarshalers.c:130
#6  0x0000003bb640ff64 in _g_closure_invoke_va (closure=closure@entry=0x15d2de0, return_value=return_value@entry=0x7fffc90ca6d0,
    instance=instance@entry=0x1898400, args=args@entry=0x7fffc90ca7d0, n_params=<optimized out>, param_types=0x15d2e10)
    at gclosure.c:831
#7  0x0000003bb642962b in g_signal_emit_valist (instance=0x1898400, signal_id=<optimized out>, detail=0,
    var_args=var_args@entry=0x7fffc90ca7d0) at gsignal.c:3218
#8  0x0000003bb642a3af in g_signal_emit (instance=instance@entry=0x1898400, signal_id=<optimized out>, detail=detail@entry=0)
    at gsignal.c:3365
#9  0x0000003f89b1e2c4 in gtk_widget_event_internal (widget=0x1898400, event=0x1716e60) at gtkwidget.c:7773
#10 0x0000003f899ecb49 in gtk_main_do_event (event=0x1716e60) at gtkmain.c:1755
#11 0x0000003f8904fae2 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
    at gdkeventsource.c:364
#12 0x0000003bb5449aeb in g_main_dispatch (context=0x15ef930) at gmain.c:3111
#13 g_main_context_dispatch (context=context@entry=0x15ef930) at gmain.c:3710
#14 0x0000003bb5449e88 in g_main_context_iterate (context=0x15ef930, block=block@entry=1, dispatch=dispatch@entry=1,
    self=<optimized out>) at gmain.c:3781
#15 0x0000003bb544a1b2 in g_main_loop_run (loop=0x1679830) at gmain.c:3975
#16 0x0000003f899ebe85 in gtk_main () at gtkmain.c:1207
#17 0x000000000040649f in main (argc=3, argv=0x7fffc90caba8) at daemon.c:391
(gdb) break g_log
Breakpoint 1 at 0x3bb5450e10: file gmessages.c, line 1075.
(gdb) run
Starting program: /usr/libexec/notification-daemon
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff180d700 (LWP 5085)]
[New Thread 0x7ffff100c700 (LWP 5086)]

Breakpoint 1, g_log (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_DEBUG,
    format=format@entry=0x40d672 "Adding id %u") at gmessages.c:1075
1075	{
(gdb) c
Continuing.
[Thread 0x7ffff100c700 (LWP 5086) exited]

Breakpoint 1, g_log (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_DEBUG,
    format=format@entry=0x40d4b7 "Bubble destroyed") at gmessages.c:1075
1075	{
(gdb) c
Continuing.

Breakpoint 1, g_log (log_domain=log_domain@entry=0x3bb54b644e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
    format=format@entry=0x3bb54bda18 "Source ID %u was not found when attempting to remove it") at gmessages.c:1075
1075	{
(gdb) c
Continuing.

(notification-daemon:5081): GLib-CRITICAL **: Source ID 17 was not found when attempting to remove it

Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x3bb54b644e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd5e0)
    at gmessages.c:1046
1046		  g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) c
Continuing.

Breakpoint 1, g_log (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_DEBUG,
    format=format@entry=0x40d539 "No queued notifications") at gmessages.c:1075
1075	{
(gdb)


So I figured out the problem lies at "#3  0x000000000040831c in add_timeout (bubble=0x1898400) at nd-bubble.c:399". Doing some digging in Google and found that glib nowadays is a bit more stringent:

https://bugzilla.gnome.org/show_bug.cgi?id=721369
GLib recently started throwing a warning when g_source_remove() is passed garbage (as per warning).

My impatient nature could help itself and attempted to patch it. It seems to be working with no apparent side effects (see notification-daemon-resetid.patch)

Created attachment 978998 [details]
skip g_source_remove

forget that previous patch, it only works for a limited number of cases. Ah well, I will let the experts have a go at it.

Created attachment 979385 [details]
notification-daemon 3.14 spec file

I create a src rpm for notification mailer updated to version 3.14. This one seems to be working fine in my LXDE desktop. This is the spec file used.

Hi Freddy and thank you for your patch. I compiled the rpm and tested it.

I'm afraid but apparently it doesn't solve the issue for my system.
The first notify works and get displayed as expected. Sadly, the second one makes notification-daemon crash.

As said before, I use fluxbox on Fedora 21 (x86_64).
Anyway, thank you for your efforts. Let me know if you have anything new to test nor need further details.

Hi JuLiuX, the patch indeed only solved a very few of the crashes. I found that the notication-daemon-3.14 (which you can compile using the spec file I uploaded) works a lot better. Not perfect, but a lot better.

Sorry, I said "patch" but I actually tried the rpm created with your spec file and encountered the behavior described in comment #14.

Note that I received a "~/rpmbuild/SOURCES/notification-daemon-0.7.6.tar.xz file not found" after the launch of "rpm -ba notification-daemon.spec". So I manually downloaded the source from "http://download.gnome.org/sources/notification-daemon/0.7/" and built it, but perhaps it was the wrong url.

Maybe did I do something wrong? In that case, could you please post a step-by-step guide to get the rpm package starting from your spec? I've got an user with the rpmdev-setuptree directories configured, but I'm afraid I'm not so familiar with the creation of a rpm.

Thank you for your patience.

JuLiuX,

I will send you the rpm in a PM.

Created attachment 981787 [details]
Source rpm for notification daemon 3.14.1

I have attacheched the src rpm I used to compile version 3.14.1. The initial version crashed on a piece of code it should never have gotten to in the first place, namely a 'g_assert_not_reached'.

Therefore I have used the G_DISABLE_ASSERT compiler flag. It works for me since, hopefully this is helpful to others as well.

Attachment 981787 [details] proposed by Freddy Willemsen works like a charm for my system with Fedora 21 x86_64. I tested it on Fedora Rawhide and it works perfectly there too.

This issue is still present on 'Fedora 22 i686 Final TC1'.

As it appears now, it makes LXDE fail at least the 'QA:Testcase_desktop_panel_basic'(https://fedoraproject.org/wiki/QA:Testcase_desktop_panel_basic) test case.

Dan, have you got any news?

This issue also happens on my FVWM laptop. Will test the attached srpm if I find time.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

There is a new version in testing which may fix this.  Could you try it and leave karma:

https://admin.fedoraproject.org/updates/FEDORA-2015-10397/notification-daemon-3.14.1-1.fc21

(In reply to Yaakov Selkowitz from comment #23)
> There is a new version in testing which may fix this.  Could you try it and
> leave karma:
> 
> https://admin.fedoraproject.org/updates/FEDORA-2015-10397/notification-
> daemon-3.14.1-1.fc21

Hi Yaakov, thank you for your efforts.

I've tested notification-daemon-3.14.1-1.fc21 on a KVM-Qemu Guest, which runs Fedora 21 LXDE. When I issue 'notify-send', the software works as expected. But, after receiving notifications coming from Network Manager's applet, it crashes and ABRT catches a "notification-daemon killed by SIGABRT". So... The issue appears to be similar to the one reported here by me months ago, but it might be different.

Additionaly, I've also tested version "3.16.1-1.fc22" on Fedora 22 (Fluxbox as WM) and it works flawlessly, without crashes, even when notifies come from nm-applet.

Feel free to ask me further tests, if needed. I may also open a new report with the full attachments of ABRT if it can be useful.

(In reply to Giulio 'juliuxpigface' from comment #24)
> I've tested notification-daemon-3.14.1-1.fc21 on a KVM-Qemu Guest, which
> runs Fedora 21 LXDE. When I issue 'notify-send', the software works as
> expected. But, after receiving notifications coming from Network Manager's
> applet, it crashes and ABRT catches a "notification-daemon killed by
> SIGABRT". So... The issue appears to be similar to the one reported here by
> me months ago, but it might be different.
> 
> Additionaly, I've also tested version "3.16.1-1.fc22" on Fedora 22 (Fluxbox
> as WM) and it works flawlessly, without crashes, even when notifies come
> from nm-applet.

Looking at the upstream commits between 3.14.1 and 3.16.1, I'm going to guess it's this one:

https://git.gnome.org/browse/notification-daemon/commit/?id=69bbecf

Here's a scratch build with that commit added:

http://koji.fedoraproject.org/koji/taskinfo?taskID=10181343

Does that help?

(In reply to Yaakov Selkowitz from comment #25)
> (In reply to Giulio 'juliuxpigface' from comment #24)
> > I've tested notification-daemon-3.14.1-1.fc21 on a KVM-Qemu Guest, which
> > runs Fedora 21 LXDE. When I issue 'notify-send', the software works as
> > expected. But, after receiving notifications coming from Network Manager's
> > applet, it crashes and ABRT catches a "notification-daemon killed by
> > SIGABRT". So... The issue appears to be similar to the one reported here by
> > me months ago, but it might be different.
> > 
> > Additionaly, I've also tested version "3.16.1-1.fc22" on Fedora 22 (Fluxbox
> > as WM) and it works flawlessly, without crashes, even when notifies come
> > from nm-applet.
> 
> Looking at the upstream commits between 3.14.1 and 3.16.1, I'm going to
> guess it's this one:
> 
> https://git.gnome.org/browse/notification-daemon/commit/?id=69bbecf
> 
> Here's a scratch build with that commit added:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=10181343
> 
> Does that help?

I tested the scratch build on the same system as comment #24. I confirm that the issue is solved.

notification-daemon-3.14.1-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/notification-daemon-3.14.1-2.fc21

Package notification-daemon-3.14.1-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing notification-daemon-3.14.1-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-10666/notification-daemon-3.14.1-2.fc21
then log in and leave karma (feedback).

notification-daemon-3.14.1-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days