GNOME Bugzilla – Bug 392032
metacity dumps core in SIGABRT handler - at least on x86_64
Last modified: 2007-04-10 13:22:58 UTC
Steps to reproduce: 1. Log out of a gnome-session while ulimit setting allow cores 2. I am not sure what else needs to be done as this does not happen with an absolute predictablity but often enough. A backtrace from different cores is looks the same Stack trace: Core was generated by `metacity --sm-client-id=default1'. Program terminated with signal 6, Aborted.
+ Trace 98817
Other information: See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220700
Just logging out of from a session is "not good enough" to produce a core; at least not usually. I was really thinking about session terminating via hitting "Shutdown", or something similar. Doing 'telinit 3' from a root terminal window should also have that effect.
Here is a newer trace which is somewhat more detailed. I got that one after I typed 'reboot' in a terminal window. Core was generated by `metacity --sm-client-id=default1'. Program terminated with signal 6, Aborted.
+ Trace 102554
This is another example of metacity bombing out on exit. "Signal 11, Segmentation fault" this time. Core was generated by `/usr/libexec/metacity-dialog --screen 0 --timestamp 144039900 --kill-window-que'. Program terminated with signal 11, Segmentation fault.
+ Trace 102559
Got that with metacity-2.17.2-1.fc7 from FC "rawhide". Should this be filed separately? It seems to be somewhat different than previous incidents.
The last stack trace looks like an accessibility bug. The other two are missing debugging symbols and don't have a single function call from metacity listed (they're all in lower level libraries like glib, gtk+, and X11). Can you still duplicate this? If so, can you get a stack trace with debugging symbols?
> Can you still duplicate this? I did not see that for quite a while. Now is April and this was reported in January. Various things changed in the meantime. If you would ask me for an additional info at the time this was happening that would not be such big deal then. If I would get that again I will try get a more detailed information but a prospect of pulling a big pile of a debugging stuff over a rather slow connection, while nobody is going to look at results for a very long time, is not that exciting.
Yeah, I understand. Sorry about that, I went AWOL while working on my dissertation for about 6 months, and most bugs (& patches!) in metacity were kind of left to dry and wither. :( Should we go ahead and close and you can reopen if you hit it again?
> Should we go ahead and close and you can reopen if you hit it again? I guess that at this moment there is nothing better to do. Chances are that hits will show up right after you closed it. :-)
Cool, then I look forward to seeing you reopen this bug with extra info in a couple hours. :)