Bug 220700 - metacity could use some care in a signal handler
metacity could use some care in a signal handler
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: metacity (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Søren Sandmann Pedersen
http://bugzilla.gnome.org/show_bug.cg...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-23 12:16 EST by Michal Jaegermann
Modified: 2014-06-18 05:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-02 14:26:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-12-23 12:16:28 EST
Description of problem:

When logged in a gnome-session, and ulimit is set to allow cores,
and you will hit, say, "Reboot" then metacity has an annoying habit
of dropping a core file which gdb indentifies like this:

Core was generated by `metacity --sm-client-id=default1'.
Program terminated with signal 6, Aborted.
#0  0x00000036606300d5 in ?? ()

A backtrace on such core looks (no metacity-debuginfo) like follows:

(gdb) where
#0  0x00000036606300d5 in raise () from /lib64/libc.so.6
#1  0x0000003660631a50 in abort () from /lib64/libc.so.6
#2  0x000000000044ae2c in g_str_equal ()
#3  0x000000000041c4b2 in g_str_equal ()
#4  0x0000003661e49d5d in _XIOError () from /usr/lib64/libX11.so.6
#5  0x0000003661e4b4bf in _XSend () from /usr/lib64/libX11.so.6
#6  0x0000003661e4b591 in _XReply () from /usr/lib64/libX11.so.6
#7  0x0000003661e432ca in XSync () from /usr/lib64/libX11.so.6
#8  0x0000003661e21bfe in XCloseDisplay () from /usr/lib64/libX11.so.6
#9  0x00002aaaabc21883 in g_str_equal ()
   from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
#10 0x0000003660632e05 in exit () from /lib64/libc.so.6
#11 0x000000366061d92b in __libc_start_main () from /lib64/libc.so.6
#12 0x000000000040d119 in g_str_equal ()
#13 0x00007fff4209d908 in ?? ()
#14 0x0000000000000000 in ?? ()

One would think that metacity should handle a termination in a tad
more graceful manner.  Turning off cores is more like a hack than
a solution.

Version-Release number of selected component (if applicable):
metacity-2.17.2-1.fc7 and earlier too.
Comment 1 Søren Sandmann Pedersen 2007-01-02 14:21:44 EST
Well, the issue here is that metacity on 64 bit apparently crashes when it loses
the connection to the X server. The backtrace looks a little strange to me -
maybe accessibility has something to do with it.

I don't think there is anything Fedora specific about it; please report it
upstream at http://bugzilla.gnome.org/

Thanks.
Comment 2 Michal Jaegermann 2007-01-11 19:19:37 EST
> The backtrace looks a little strange to me

Will you be happier with that one?  I got it today after typing
in a terminal window 'reboot'.  'metacity' drops cores quite
regularly albeit not in an absolutely predictable manner.

Core was generated by `metacity --sm-client-id=default1'.
Program terminated with signal 6, Aborted.
#0  0x00000036606300d5 in raise () from /lib64/libc.so.6
(gdb) where
#0  0x00000036606300d5 in raise () from /lib64/libc.so.6
#1  0x0000003660631a50 in abort () from /lib64/libc.so.6
#2  0x000000000044ae2c in g_str_equal ()
#3  0x000000000041c4b2 in g_str_equal ()
#4  0x0000003968a49d5d in _XIOError () from /usr/lib64/libX11.so.6
#5  0x0000003968a4b4bf in _XSend () from /usr/lib64/libX11.so.6
#6  0x0000003968a4b591 in _XReply () from /usr/lib64/libX11.so.6
#7  0x0000003968a432ca in XSync () from /usr/lib64/libX11.so.6
#8  0x0000003968a21bfe in XCloseDisplay () from /usr/lib64/libX11.so.6
#9  0x00002aaaab345883 in g_str_equal ()
   from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
#10 0x0000003660632e05 in exit () from /lib64/libc.so.6
#11 0x000000000041c479 in g_str_equal ()
#12 0x0000003968a49d5d in _XIOError () from /usr/lib64/libX11.so.6
#13 0x0000003968a4b4bf in _XSend () from /usr/lib64/libX11.so.6
#14 0x0000003968a4b591 in _XReply () from /usr/lib64/libX11.so.6
#15 0x0000003968a2d5ca in XGetSelectionOwner () from /usr/lib64/libX11.so.6
#16 0x00000030bec5ea5e in gdk_xid_table_lookup ()
   from /usr/lib64/libgdk-x11-2.0.so.0
#17 0x00000030bec5eb5d in gdk_xid_table_lookup ()
   from /usr/lib64/libgdk-x11-2.0.so.0
#18 0x00000030bec46c06 in gdk_add_client_message_filter ()
   from /usr/lib64/libgdk-x11-2.0.so.0
#19 0x00000030bec4348c in gdk_x11_drawable_get_xdisplay ()
   from /usr/lib64/libgdk-x11-2.0.so.0
#20 0x00000030bec44d2d in gdk_events_pending ()
   from /usr/lib64/libgdk-x11-2.0.so.0
#21 0x00000030bec463b2 in gdk_events_pending ()
   from /usr/lib64/libgdk-x11-2.0.so.0
#22 0x00000030bec467ce in gdk_add_client_message_filter ()
   from /usr/lib64/libgdk-x11-2.0.so.0
#23 0x000000325e02d014 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#24 0x000000325e02fe4d in g_main_context_check () from /lib64/libglib-2.0.so.0
#25 0x000000325e03015a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#26 0x0000000000427b83 in g_str_equal ()
#27 0x000000366061d924 in __libc_start_main () from /lib64/libc.so.6
#28 0x000000000040d119 in g_str_equal ()
#29 0x00007fffb2259ac8 in ?? ()
#30 0x0000000000000000 in ?? ()
(gdb)
Comment 3 Michal Jaegermann 2007-01-14 16:40:45 EST
And here is still another kind of bomb from metacity:

Core was generated by `/usr/libexec/metacity-dialog --screen 0 --timestamp
144039900 --kill-window-que'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000003660675430 in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003660675430 in strlen () from /lib64/libc.so.6
#1  0x0000003261a2a381 in giop_send_buffer_append_string ()
   from /usr/lib64/libORBit-2.so.0
#2  0x0000003261a36b4c in ORBit_marshal_value ()
   from /usr/lib64/libORBit-2.so.0
#3  0x0000003261a3689d in ORBit_marshal_value ()
   from /usr/lib64/libORBit-2.so.0
#4  0x0000003261a36c98 in ORBit_marshal_any () from /usr/lib64/libORBit-2.so.0
#5  0x0000003261a369d5 in ORBit_marshal_value ()
   from /usr/lib64/libORBit-2.so.0
#6  0x0000003261a3689d in ORBit_marshal_value ()
   from /usr/lib64/libORBit-2.so.0
#7  0x0000003261a2ed01 in ORBit_small_allocbuf ()
   from /usr/lib64/libORBit-2.so.0
#8  0x0000003261a2f08d in ORBit_small_invoke_stub ()
   from /usr/lib64/libORBit-2.so.0
#9  0x000000396cc290cc in Accessibility_EventListener_notifyEvent ()
   from /usr/lib64/libspi.so.0
#10 0x00002aaaab32b4b0 in gtk_main_quit ()
   from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
#11 0x00002aaaab32b7c9 in gtk_main_quit ()
   from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
#12 0x0000003660632e05 in exit () from /lib64/libc.so.6
#13 0x000000366061d92b in __libc_start_main () from /lib64/libc.so.6
#14 0x0000000000401fe9 in gtk_main_quit ()
#15 0x00007fff77d1b508 in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb)

Should that be filed separately?  These traces are different.
I found three rather recent cores of that sort.  Two from before
an update to metacity-2.17.2-1.fc7 and one after that.
Comment 4 Søren Sandmann Pedersen 2007-01-15 12:58:35 EST
This Red Hat bug is closed, which means I am not going to look at it.

Crashes such as these are much better handled upstream. 

Note You need to log in before you can comment on or make changes to this bug.