Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 193815 - metacity segfaults on shutdown
Summary: metacity segfaults on shutdown
Alias: None
Product: Fedora
Classification: Fedora
Component: metacity
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact:
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
Reported: 2006-06-01 19:46 UTC by Michal Jaegermann
Modified: 2014-06-18 09:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-08-15 02:56:49 UTC

Attachments (Terms of Use)

Description Michal Jaegermann 2006-06-01 19:46:25 UTC
Description of problem:

A recent collection from /var/log/messages:

metacity[15432]: segfault at 0000000000000010 rip 0000000000414c31 rsp
00007fffd369bab0 error 4
metacity[16566]: segfault at 0000000000000010 rip 0000000000414c31 rsp
00007fffdadb90e0 error 4
metacity[2660]: segfault at 0000000000000010 rip 0000000000414c31 rsp
00007fff95b11f20 error 4

AFAICS this this happens consistently on shutdown, and the next message
logged will quite likely be something like "gconfd (root-7781): Exiting".
OTOH 'telinit 1' from a terminal window does not seem to be enough.

Looking back through my logs this was happening with earlier versions
of metacity as well.

Version-Release number of selected component (if applicable):

How reproducible:
looks pretty consistent but when we are shutting down

Comment 1 Michal Jaegermann 2006-06-05 22:46:08 UTC
I raised core ulimit and ended up with few core files from metacity.
With metacity-debuginfo looking at these with gdb shows a consistent
picture.  A segfault happens always here:

(gdb) where
#0  meta_compositor_unref (compositor=0x0) at compositor.c:160
#1  0x000000000041a245 in meta_display_close (display=0x6dd660)
    at display.c:903
#2  0x000000000042b7f9 in main (argc=1, argv=0x7fffdd704068) at main.c:402
#3  0x00000030bfb1c864 in ?? ()
#4  0x00007fffdd704068 in ?? ()
#5  0x00007fffdd704068 in ?? ()
#6  0x00000002aaaab000 in ?? ()
#7  0x000000000042b100 in meta_restart () at main.c:453
#8  0x00000030bfa19be0 in _dl_argv_internal () from /lib64/
#9  0x1e798c090cb2ec13 in ?? ()
#10 0x0000000000000000 in ?? ()

where the code looks like this:

(gdb) list
157     static void
158     remove_repair_idle (MetaCompositor *compositor)
159     {
160       if (compositor->repair_idle)
161         {
162           meta_topic (META_DEBUG_COMPOSITOR, "Damage idle removed\n");
164           g_source_remove (compositor->repair_idle);
(gdb) p compositor
$2 = (MetaCompositor *) 0x0

In other words a check which would prevent calling 'remove_repair_idle()'
with a NULL 'compositor' would prevent that bomb.  If this is really
a legitimate value for that variable, and if it may contain garbage under
some circumstance, I cannot tell.

Comment 2 Michal Jaegermann 2006-07-03 19:06:07 UTC
I found very familiar looking

metacity[14293]: segfault at 0000000000000010 rip 00000000004141f1 rsp
00007fffffc36c50 error 4

on a shutdown with metacity-2.14.3-1.fc5.1 from FC5 as well.

Comment 3 Matthias Clasen 2006-08-15 02:56:49 UTC
Closing bugs related to the metacity compositor, since we no longer develop it.

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