Red Hat Bugzilla – Bug 737280
metacity exits soon after fallback mode session starts
Last modified: 2015-02-17 08:52:32 EST
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):
Open terminal, type about 3 chars, window decorations go away every time.
Steps to Reproduce:
disappearing window manager in fallback mode
window manager that continues to function
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.)
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.
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.
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.
Created attachment 522576 [details]
dmesg output for F16 with RC4 kernel and metacity running
Created attachment 522577 [details]
dmesg output for Rawhide with RC4 kernel and metacity not running
this bug happens with the F15 kernel (126.96.36.199-5) as well, FWIW. (I got into that config by doing a preupgrade).
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.
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.
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).
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.
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.
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
no, latest is rc6:
OK, I installed the RC6 kernel plus today's batch of Rawhide updates. No change.
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.
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)
#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?
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".
After installing today's Rawhide updates, I no longer see this behavior.
(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.
Created attachment 526441 [details]
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...
Created attachment 526442 [details]
result of print *style
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
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
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 ;-)
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:
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.
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.