Bug 1092491

Summary: [abrt] mate-notification-daemon: g_type_check_instance_cast(): mate-notification-daemon killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Robin Hack <rhack>
Component: mate-notification-daemonAssignee: Dan Mashal <dan.mashal>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dan.mashal, jfilak, krzysiek_warta, raveit65.sun, rdieter, stefano
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/d47d3076169f8ac9d88d0e197c58220da9762da1
Whiteboard: abrt_hash:8d65ba35be8703050c3dc6cbc7dfff8e41bb0508
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-09 18:41:22 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: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Robin Hack 2014-04-29 12:24:34 UTC 
Version-Release number of selected component:
mate-notification-daemon-1.6.1-2.fc20

Additional info:
reporter:       libreport-2.2.1
backtrace_rating: 4
cmdline:        /usr/libexec/mate-notification-daemon
crash_function: g_type_check_instance_cast
executable:     /usr/libexec/mate-notification-daemon
kernel:         3.13.7-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            20787

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 g_type_check_instance_cast at gtype.c:4003
 #1 gdk_x11_screen_get_screen_number at gdkscreen-x11.c:607
 #2 get_work_area at stack.c:69
 #3 notify_stack_shift_notifications at stack.c:267
 #4 notify_stack_remove_window at stack.c:373
 #9 gtk_object_dispose at gtkobject.c:421
 #11 _notify_timeout_destroy at daemon.c:149
 #12 g_hash_table_foreach_remove_or_steal at ghash.c:1412
 #13 g_hash_table_foreach_remove at ghash.c:1456
 #14 _check_expiration at daemon.c:741

Potential duplicate: bug 991671
Comment 1 Robin Hack 2014-04-29 12:24:39 UTC 
Created attachment 890763 [details]
File: backtrace
Comment 2 Robin Hack 2014-04-29 12:24:41 UTC 
Created attachment 890764 [details]
File: cgroup
Comment 3 Robin Hack 2014-04-29 12:24:44 UTC 
Created attachment 890765 [details]
File: core_backtrace
Comment 4 Robin Hack 2014-04-29 12:24:46 UTC 
Created attachment 890766 [details]
File: dso_list
Comment 5 Robin Hack 2014-04-29 12:24:49 UTC 
Created attachment 890767 [details]
File: environ
Comment 6 Robin Hack 2014-04-29 12:24:53 UTC 
Created attachment 890769 [details]
File: exploitable
Comment 7 Robin Hack 2014-04-29 12:24:55 UTC 
Created attachment 890771 [details]
File: limits
Comment 8 Robin Hack 2014-04-29 12:24:58 UTC 
Created attachment 890773 [details]
File: maps
Comment 9 Robin Hack 2014-04-29 12:25:01 UTC 
Created attachment 890775 [details]
File: open_fds
Comment 10 Robin Hack 2014-04-29 12:25:03 UTC 
Created attachment 890776 [details]
File: proc_pid_status
Comment 11 Robin Hack 2014-04-29 12:25:07 UTC 
Created attachment 890778 [details]
File: var_log_messages
Comment 12 Wolfgang Ulbrich 2014-06-21 16:46:10 UTC 
Can you describe a little more detailed what happend?
Did this issue occurs frequently ?
Comment 13 Wolfgang Ulbrich 2014-07-09 18:41:22 UTC 
No answer from reporter!
Comment 14 Robin Hack 2014-07-10 11:08:04 UTC 
I don't know. I think that I checked this option in abrt.
Comment 15 Jakub Filak 2014-09-01 05:54:06 UTC 
(In reply to Robin Hack from comment #14)
> I don't know. I think that I checked this option in abrt.

You checked that option, but this bug cannot be fixed without a good reproducer. We (maintainers) often ask for more details, because we think that users are often just "lazy" :) to typewrite and ABRT allows them to submit reports without description.
Comment 16 Robin Hack 2014-09-01 07:22:24 UTC 
(In reply to Jakub Filak from comment #15)
> (In reply to Robin Hack from comment #14)
> > I don't know. I think that I checked this option in abrt.
> 
> You checked that option, but this bug cannot be fixed without a good
> reproducer. We (maintainers) often ask for more details, because we think
> that users are often just "lazy" :) to typewrite and ABRT allows them to
> submit reports without description.
Wrong. 
Devels are lazy too ;). They don't wanna check what happened.
I'm not lazy but I sometimes just run process in background and switch to another application. Or I just start to do more than one thing at once...
Start more than one application at time etc.. sometimes something crashed I don't even know that this application ran.. (parts of mate desktop).

Also.. this is notification daemon. I really don't know whicn message shot them down..
Comment 17 Wolfgang Ulbrich 2014-09-01 07:56:01 UTC 
Hmm,
maybe you don't know how fixing a bug works.
First, i'm not a C coder, i'm only the maintainer who build the packages for Fedora.
The mate packages are mostly developed by guys from debian and gentoo.
So, my job is to filter out what causes the issue and forwarding the issue to upstream if it is a prob with the code.
But for this i need to reproduce it.
Sorry, i don't have the issue on my systems.
Also mate devs need a valid decription and steps to reproduce, a backtrace only isn't sufficient.
Personaly, i don't send a bug with abrt if i don't know exactly what's happend.
Believe me if it is really a bug the issue come back and you can send them at this time with more informations.
I prefer this way instead of creating reports which are only for the records and can't be fixed.
Comment 18 Robin Hack 2014-09-01 08:23:10 UTC 
Thanks for your comment.  I also takled with jfilak and I finally know how abrt works as a whole. Thanks you and jfilak for good reaction to my troll-like comment.