Bug 737280 - metacity exits soon after fallback mode session starts
Summary: metacity exits soon after fallback mode session starts
Alias: None
Product: Fedora
Classification: Fedora
Component: metacity
Version: 19
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-10 15:40 UTC by Tom Horsley
Modified: 2015-02-17 13:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-17 13:52:32 UTC

Attachments (Terms of Use)
gdb backtrace from metacity crash (18.99 KB, text/plain)
2011-09-10 20:01 UTC, Tom London
no flags Details
dmesg output for F16 with RC4 kernel and metacity running (12.35 KB, application/x-gzip)
2011-09-11 03:42 UTC, Andre Robatino
no flags Details
dmesg output for Rawhide with RC4 kernel and metacity not running (11.94 KB, application/x-gzip)
2011-09-11 03:43 UTC, Andre Robatino
no flags Details
Strace of metacity as it decides to exit (307.08 KB, application/octet-stream)
2011-09-16 20:04 UTC, Jerry James
no flags Details
another backtrace (25.21 KB, text/plain)
2011-10-05 07:56 UTC, David Tardon
no flags Details
result of print *style (585 bytes, text/plain)
2011-10-05 07:57 UTC, David Tardon
no flags Details
always initialize button layout (2.76 KB, patch)
2011-10-05 11:33 UTC, David Tardon
no flags Details | Diff

Description Tom Horsley 2011-09-10 15:40:54 UTC
Description of problem:

Just tried f16 Beta TC2 on a spare test machine. It has
a GeForce GT 430 card in it, which cannot do 3D with the
nouveau driver, so gnome 3 switches to fallback mode.

In fallback mode whenever I bring up a gnome-terminal,
about 5 to 10 seconds later the window manager disappears.
All the window decorations go away and moving, raising,
lowering, etc is no longer possible.

However, I never get an ABRT report of any kind as near
as I can tell. It is more like it just decides to exit
rather than crashing.

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


How reproducible:

Open terminal, type about 3 chars, window decorations go away every time.

Steps to Reproduce:
1.see above
Actual results:
disappearing window manager in fallback mode

Expected results:
window manager that continues to function

Additional info:

Comment 1 Andre Robatino 2011-09-10 16:12:12 UTC
I've also seen this the past few days on both F16 and Rawhide in fallback mode (in a VirtualBox guest). I've also seen it during 16 Beta TC2 testing immediately after a clean non-networked default DVD install in a KVM guest (both i386 and x86_64). Occasionally, the window manager is running by itself. If it isn't, I can start it manually in a terminal with "metacity &". (I've never seen it exit - when I log in, to all appearances it's either running, or not, and stays that way unless I start it manually.)

Comment 2 Tom London 2011-09-10 20:01:30 UTC
Created attachment 522540 [details]
gdb backtrace from metacity crash

Not sure this is the same thing, but I'm seeing this core dump (segfault) from metacity.

Comment 3 Andre Robatino 2011-09-11 01:36:45 UTC
After today's F16 updates, including a new kernel, I haven't seen this in the last several boots and logins. This problem started several days ago, the current metacity is over a month old. Also, one time metacity didn't start, I looked at dmesg output and saw a kernel trace, similar to the one I reported in bug 736941 (marked as duplicate of bug 732572). The latest kernel is supposed to fix that bug. So one thing to try is to check if it only appears when booting into the previous kernel (3.1.0-0.rc4.git0.0.fc16). I installed that kernel on August 30, which seems longer than I remember this problem existing, but I could be wrong.

Comment 4 Andre Robatino 2011-09-11 03:40:49 UTC
On further testing, it looks like to see this you need to both boot into the RC4 kernel, generating a call trace, and for the call trace to be a specific type. In F16, there are currently no broken gnome dependencies, so all those packages are updated. When I boot F16 with the RC4 kernel, metacity is running, and I see a call trace, but a different-looking one (referring to dconf-service). When I boot Rawhide (which still has broken gnome dependencies which I can't update) with its RC4 kernel, metacity is not running, and I see a call trace referring to gnome-panel. If I boot Rawhide into its RC5 kernel, I don't see the call trace and metacity is running.

So I'm guessing that with the combination of the RC5 kernel and the full set of updated gnome packages, this should be pretty well fixed by now.

Comment 5 Andre Robatino 2011-09-11 03:42:00 UTC
Created attachment 522576 [details]
dmesg output for F16 with RC4 kernel and metacity running

Comment 6 Andre Robatino 2011-09-11 03:43:06 UTC
Created attachment 522577 [details]
dmesg output for Rawhide with RC4 kernel and metacity not running

Comment 7 Adam Williamson 2011-09-12 23:28:28 UTC
this bug happens with the F15 kernel ( as well, FWIW. (I got into that config by doing a preupgrade).

Comment 8 Tom Horsley 2011-09-13 10:26:26 UTC
I got all the latest updates for f16 on my system last night, and I can
now run a gnome-terminal and even use it for a long time and do not see
metacity disappear anymore, so it looks like the latest updates fix this.

Comment 9 Jerry James 2011-09-15 20:00:50 UTC
I'm running Rawhide in a VM, and have had this behavior (metacity exiting a few seconds after logging in) for several days.  Today, I finally got annoyed enough to go looking for a bug.  So, with all of today's Rawhide updates, which includes kernel 3.1.0-0.rc6.git0.0.fc17.x86_64, I am still seeing this bug.  Like others have reported, if I manually restart metacity, the new instance does not exit.

Comment 10 Andre Robatino 2011-09-15 21:30:24 UTC
Do you see any call trace in dmesg's output or in /var/log/messages? Also, until a day or two ago I had a long list of non-updatable packages in Rawhide, but running yum distro-sync fixed that (a few packages needed to be downgraded to let the rest update).

Comment 11 Jerry James 2011-09-15 21:59:40 UTC
No, I see no traces in either dmesg's output or /var/log/messages.  I have been using yum distro-sync, so this really is a fully updated Rawhide.  Also, "package-cleanup --orphans" lists only the 2 older kernels, as expected.  I have 2 Rawhide VMs, one x86_64, one i686, and both show this behavior.

Comment 12 Adam Williamson 2011-09-15 22:15:29 UTC
jerry: does it happen if you use the current f16 kernel? It's versioned the same as f17, but there's a significant difference: the f16 one has debugging disabled.

Comment 13 Jerry James 2011-09-15 22:40:16 UTC
Unless I'm looking in the wrong place, the latest F-16 kernel is RC5.  The latest Rawhide kernel is RC6.  But anyway, I installed the RC5 F-16 kernel on my i686 Rawhide VM, rebooted, logged in, and metacity exited after a few seconds.  And, yes, I double checked that I booted into the correct kernel. :-)

$ uname -r

Comment 14 Adam Williamson 2011-09-15 22:55:36 UTC
no, latest is rc6:


Comment 15 Jerry James 2011-09-16 17:34:18 UTC
OK, I installed the RC6 kernel plus today's batch of Rawhide updates.  No change.

Comment 16 Jerry James 2011-09-16 20:04:08 UTC
Created attachment 523619 [details]
Strace of metacity as it decides to exit

Here's a little more information.  I'm attaching the results of running this:

strace -tt -v -s128 -ff -o metacity -p`pidof metacity`

right after logging in.  Notice the two window manager warnings, which occur immediately before metacity exits.

Comment 17 Jerry James 2011-09-16 20:54:18 UTC
No, ignore those warnings.  They occur after metacity already decided to exit.  On a hunch, I put a breakpoint on meta_quit, and it triggered (i686 machine):

#0  meta_quit (code=META_EXIT_SUCCESS) at core/main.c:623
#1  0x4d2280b4 in _SmcProcessMessage (iceConn=0x8d7c720, clientData=0x8d5c9a8,
    opcode=9, length=0, swap=0, replyWait=0x0, replyReadyRet=0xbfe73684)
    at sm_process.c:324
#2  0x4d219d88 in IceProcessMessages (iceConn=0x8d7c720, replyWait=0x0,
    replyReadyRet=0x0) at process.c:341
#3  0x0807b050 in process_ice_messages (channel=0x8d5e5e0, condition=G_IO_IN,
    client_data=0x8d7c720) at core/session.c:102
#4  0x4bc272cf in g_io_unix_dispatch (source=0x8d5ea50, callback=
    0x807b030 <process_ice_messages>, user_data=0x8d7c720) at giounix.c:166
#5  0x4bbe05bf in g_main_dispatch (context=0x8ce7110) at gmain.c:2441
#6  g_main_context_dispatch (context=0x8ce7110) at gmain.c:3011
#7  0x4bbe0d00 in g_main_context_iterate (context=0x8ce7110, block=1270806496,
    dispatch=1, self=0x8cdf060) at gmain.c:3089
#8  0x4bbe1337 in g_main_loop_run (loop=0x8ce77f8) at gmain.c:3297
#9  0x08053b88 in main (argc=1, argv=0xbfe73ca4) at core/main.c:584

The location in frame 1 means that metacity received an SM_Die message from the session manager.  So metacity is behaving as it should, obediently shutting down when the session manager tells it to do so.  Why is the session manager telling it to shut down?

Comment 18 Andre Robatino 2011-09-19 04:38:54 UTC
In the last day or two I've started seeing this on every Rawhide login. It happens with both the rc5 and rc6 kernel (I didn't check the earlier ones), and if I log out and back in, it happens again. As before, if I start metacity manually it doesn't exit. There is no call trace in dmesg output. At the moment I'm not seeing it in F16. Both are fully updated using "yum --skip-broken distro-sync".

Comment 19 Jerry James 2011-09-21 19:51:11 UTC
After installing today's Rawhide updates, I no longer see this behavior.

Comment 20 Andre Robatino 2011-09-23 14:19:19 UTC
(In reply to comment #19)
> After installing today's Rawhide updates, I no longer see this behavior.

I stopped seeing it around the same time.

Comment 21 David Tardon 2011-10-05 07:56:05 UTC
Created attachment 526441 [details]
another backtrace

I am seeing this crash too. It happens every time I try to open any window, which is pretty annoying, to put it mildly. I tried to just sit and stare at the pretty background image, but I always got bored after a while and tried to actually do something...

Comment 22 David Tardon 2011-10-05 07:57:25 UTC
Created attachment 526442 [details]
result of print *style

Comment 23 David Tardon 2011-10-05 11:27:23 UTC
So I have found what the problem was here: metacity.schema was not processed correctly on update. Test:

gconftool-2 --get-schema-name /apps/metacity/general/button_layout

should return /schemas/apps/metacity/general/button_layout if everything
is okay.

It is possible to avoid the immediate crash by running

gconftool-2 -s /apps/metacity/general/button_layout -t string :minimize,maximize,close

, but the right solution is to run

GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule /etc/gconf/schemas/metacity.schemas

as root.

Comment 24 David Tardon 2011-10-05 11:33:05 UTC
Created attachment 526470 [details]
always initialize button layout

I should note that there would be no crash if metacity initialized the new_layout structure in button_layout_handler even when the config string is NULL ;-)

Comment 25 Fedora End Of Life 2013-04-03 16:37:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 26 Fedora End Of Life 2015-01-09 16:46:46 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 27 Fedora End Of Life 2015-02-17 13:52:32 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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