Bug 737280

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 (2.6.40.4-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
3.1.0-0.rc5.git0.0.fc16.i686.PAE

no, latest is rc6:

https://admin.fedoraproject.org/updates/FEDORA-2011-12732

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)
    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?

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]
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...

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
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.

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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

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
bug.

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