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
Created attachment 890763 [details] File: backtrace
Created attachment 890764 [details] File: cgroup
Created attachment 890765 [details] File: core_backtrace
Created attachment 890766 [details] File: dso_list
Created attachment 890767 [details] File: environ
Created attachment 890769 [details] File: exploitable
Created attachment 890771 [details] File: limits
Created attachment 890773 [details] File: maps
Created attachment 890775 [details] File: open_fds
Created attachment 890776 [details] File: proc_pid_status
Created attachment 890778 [details] File: var_log_messages
Can you describe a little more detailed what happend? Did this issue occurs frequently ?
No answer from reporter!
I don't know. I think that I checked this option in abrt.
(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.
(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..
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.
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.