After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 392032 - metacity dumps core in SIGABRT handler - at least on x86_64
metacity dumps core in SIGABRT handler - at least on x86_64
Status: RESOLVED INCOMPLETE
Product: metacity
Classification: Other
Component: general
2.17.x
Other All
: Normal critical
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2007-01-02 20:27 UTC by Michal Jaegermann
Modified: 2007-04-10 13:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Michal Jaegermann 2007-01-02 20:27:20 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.
  • #0 ??
  • #0 raise
    from /lib64/libc.so.6
  • #1 abort
    from /lib64/libc.so.6
  • #2 g_str_equal
  • #3 g_str_equal
  • #4 _XIOError
    from /usr/lib64/libX11.so.6
  • #5 _XSend
    from /usr/lib64/libX11.so.6
  • #6 _XReply
    from /usr/lib64/libX11.so.6
  • #7 XSync
    from /usr/lib64/libX11.so.6
  • #8 XCloseDisplay
    from /usr/lib64/libX11.so.6
  • #9 g_str_equal
    from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
  • #10 exit
    from /lib64/libc.so.6
  • #11 __libc_start_main
    from /lib64/libc.so.6
  • #12 g_str_equal
  • #13 ??
  • #14 ??



Other information:
See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220700
Comment 1 Michal Jaegermann 2007-01-03 06:19:13 UTC
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.
Comment 2 Michal Jaegermann 2007-01-16 00:05:42 UTC
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.
  • #0 raise
    from /lib64/libc.so.6
  • #0 raise
    from /lib64/libc.so.6
  • #1 abort
    from /lib64/libc.so.6
  • #2 g_str_equal
  • #3 g_str_equal
  • #4 _XIOError
    from /usr/lib64/libX11.so.6
  • #5 _XSend
    from /usr/lib64/libX11.so.6
  • #6 _XReply
    from /usr/lib64/libX11.so.6
  • #7 XSync
    from /usr/lib64/libX11.so.6
  • #8 XCloseDisplay
    from /usr/lib64/libX11.so.6
  • #9 g_str_equal
    from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
  • #10 exit
    from /lib64/libc.so.6
  • #11 g_str_equal
  • #12 _XIOError
    from /usr/lib64/libX11.so.6
  • #13 _XSend
    from /usr/lib64/libX11.so.6
  • #14 _XReply
    from /usr/lib64/libX11.so.6
  • #15 XGetSelectionOwner
    from /usr/lib64/libX11.so.6
  • #16 gdk_xid_table_lookup
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #17 gdk_xid_table_lookup
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #18 gdk_add_client_message_filter
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #19 gdk_x11_drawable_get_xdisplay
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #20 gdk_events_pending
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #21 gdk_events_pending
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #22 gdk_add_client_message_filter
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #23 g_main_context_dispatch
    from /lib64/libglib-2.0.so.0
  • #24 g_main_context_check
    from /lib64/libglib-2.0.so.0
  • #25 g_main_loop_run
    from /lib64/libglib-2.0.so.0
  • #26 g_str_equal
  • #27 __libc_start_main
    from /lib64/libc.so.6
  • #28 g_str_equal
  • #29 ??
  • #30 ??

Comment 3 Michal Jaegermann 2007-01-16 00:16:25 UTC
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.
  • #0 strlen
    from /lib64/libc.so.6
  • #0 strlen
    from /lib64/libc.so.6
  • #1 giop_send_buffer_append_string
    from /usr/lib64/libORBit-2.so.0
  • #2 ORBit_marshal_value
    from /usr/lib64/libORBit-2.so.0
  • #3 ORBit_marshal_value
    from /usr/lib64/libORBit-2.so.0
  • #4 ORBit_marshal_any
    from /usr/lib64/libORBit-2.so.0
  • #5 ORBit_marshal_value
    from /usr/lib64/libORBit-2.so.0
  • #6 ORBit_marshal_value
    from /usr/lib64/libORBit-2.so.0
  • #7 ORBit_small_allocbuf
    from /usr/lib64/libORBit-2.so.0
  • #8 ORBit_small_invoke_stub
    from /usr/lib64/libORBit-2.so.0
  • #9 Accessibility_EventListener_notifyEvent
    from /usr/lib64/libspi.so.0
  • #10 gtk_main_quit
    from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
  • #11 gtk_main_quit
    from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
  • #12 exit
    from /lib64/libc.so.6
  • #13 __libc_start_main
    from /lib64/libc.so.6
  • #14 gtk_main_quit
  • #15 ??
  • #16 ??

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.
Comment 4 Elijah Newren 2007-04-09 21:14:45 UTC
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?
Comment 5 Michal Jaegermann 2007-04-10 01:45:12 UTC
> 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.
Comment 6 Elijah Newren 2007-04-10 02:04:51 UTC
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?
Comment 7 Michal Jaegermann 2007-04-10 06:12:24 UTC
> 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. :-)
Comment 8 Elijah Newren 2007-04-10 13:22:58 UTC
Cool, then I look forward to seeing you reopen this bug with extra info in a couple hours.  :)