Bug 1008014

Summary: [abrt] mate-notification-daemon-1.6.0-2.fc19: g_return_if_fail_warning: Process /usr/libexec/mate-notification-daemon was killed by signal 5 (SIGTRAP)
Product: [Fedora] Fedora Reporter: A.J. Bonnema <abonnema56>
Component: mate-notification-daemonAssignee: Dan Mashal <dan.mashal>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: dan.mashal, raveit65.sun, rdieter, stefano
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: abrt_hash:599890361b17bba984aec4f3401b90f3ea98ccd0
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-27 19:54:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status none

Description A.J. Bonnema 2013-09-13 19:21:51 UTC 
Version-Release number of selected component:
mate-notification-daemon-1.6.0-2.fc19

Additional info:
reporter:       libreport-2.1.6
backtrace_rating: 4
cmdline:        /usr/libexec/mate-notification-daemon
crash_function: g_return_if_fail_warning
executable:     /usr/libexec/mate-notification-daemon
kernel:         3.10.10-200.fc19.x86_64
runlevel:       N 5
uid:            1000
var_log_messages: Sep 13 10:14:10 mahatma abrt[3077]: Saved core dump of pid 3074 (/usr/libexec/mate-notification-daemon) to /var/tmp/abrt/ccpp-2013-09-13-10:14:10-3074 (19607552 bytes)

Truncated backtrace:
Thread no. 1 (9 frames)
 #2 g_return_if_fail_warning at gmessages.c:1019
 #3 g_value_get_uchar at gvaluetypes.c:732
 #4 set_notification_hints at nodoka-theme.c:1010
 #5 notify_daemon_notify_handler at daemon.c:1369
 #6 dbus_glib_marshal_notification_daemon_VOID__STRING_UINT_STRING_STRING_STRING_BOXED_BOXED_INT_POINTER at notificationdaemon-dbus-glue.h:102
 #7 invoke_object_method at dbus-gobject.c:1899
 #8 object_registration_message at dbus-gobject.c:2161
 #9 _dbus_object_tree_dispatch_and_unlock at dbus-object-tree.c:862
 #16 gtk_main at gtkmain.c:1257
Comment 1 A.J. Bonnema 2013-09-13 19:21:56 UTC 
Created attachment 797487 [details]
File: backtrace
Comment 2 A.J. Bonnema 2013-09-13 19:22:00 UTC 
Created attachment 797488 [details]
File: cgroup
Comment 3 A.J. Bonnema 2013-09-13 19:22:04 UTC 
Created attachment 797489 [details]
File: core_backtrace
Comment 4 A.J. Bonnema 2013-09-13 19:22:07 UTC 
Created attachment 797490 [details]
File: dso_list
Comment 5 A.J. Bonnema 2013-09-13 19:22:14 UTC 
Created attachment 797491 [details]
File: environ
Comment 6 A.J. Bonnema 2013-09-13 19:22:17 UTC 
Created attachment 797492 [details]
File: limits
Comment 7 A.J. Bonnema 2013-09-13 19:22:21 UTC 
Created attachment 797493 [details]
File: maps
Comment 8 A.J. Bonnema 2013-09-13 19:22:24 UTC 
Created attachment 797494 [details]
File: open_fds
Comment 9 A.J. Bonnema 2013-09-13 19:22:27 UTC 
Created attachment 797495 [details]
File: proc_pid_status
Comment 10 Wolfgang Ulbrich 2013-09-28 15:46:25 UTC 
Can you describe a little more detailed what happend?
Did this issue occurs frequently ?
Comment 11 A.J. Bonnema 2013-09-29 06:59:25 UTC 
At the time I had this error frequently, and I ignored it most of the time. But I realise I was not on the mate desktop. Now that I am on the mate desktop, the error no longer occurs.

About the circumstances: it usually had this error right after logon, but occurred after that multiple times. Thats why I started ignoring it.

P.s. Is it possible that in some way I shut down the error reporting process? I ask because I now get zero errors, where I used to get at least a few errors a day.
Comment 12 Wolfgang Ulbrich 2013-09-30 09:49:19 UTC 
(In reply to A.J. Bonnema from comment #11)
> At the time I had this error frequently, and I ignored it most of the time.
> But I realise I was not on the mate desktop. Now that I am on the mate
> desktop, the error no longer occurs.
This means you was using another DE when the issue happend?
> 
> About the circumstances: it usually had this error right after logon, but
> occurred after that multiple times. Thats why I started ignoring it.
Abrt stores issues and if you start the abrt applet with autostart at login it display the issue.
But it displays also issues at this time which happend during shutdown, for example.
> 
> P.s. Is it possible that in some way I shut down the error reporting
> process? I ask because I now get zero errors, where I used to get at least a
> few errors a day.
If you don't disable the abrt services with systemctl and disable it in autostart, abrt should be active.
Comment 13 A.J. Bonnema 2013-10-02 13:28:17 UTC 
I was indeed working on a different desktop. I think it was xfce. I imagine that invalidates the abort?
Comment 14 Wolfgang Ulbrich 2013-10-02 20:10:51 UTC 
Good hint, mate and xfce use both a provides 'desktop-notification-daemon' in spec file.
I will investigate more time in this direction.
Feel free to post it here if i happens again.
Comment 15 Wolfgang Ulbrich 2013-12-27 19:54:13 UTC 

*** This bug has been marked as a duplicate of bug 1046716 ***