Red Hat Bugzilla – Bug 1002055
[abrt] gnome-shell-3.9.90-1.fc20: g_variant_valist_new_nnp: Process /usr/bin/gnome-shell was killed by signal 5 (SIGTRAP)
Last modified: 2013-09-06 08:59:43 EDT
Description of problem:
I put F20 Alpha TC1 i386 Live onto USB flash drive using dd and then booted it on this computer. It contains nvidia graphics and there's some kernel error during boot, I don't know whether it is related. After boot, I see just "Oh no something's wrong" screen.
Version-Release number of selected component:
runlevel: N 5
Thread no. 1 (10 frames)
#2 g_variant_valist_new_nnp at gvariant.c:4159
#3 g_variant_valist_new_leaf at gvariant.c:4387
#4 g_variant_valist_new at gvariant.c:4569
#6 g_variant_new_va at gvariant.c:4778
#7 g_variant_builder_add at gvariant.c:4930
#8 meta_monitor_manager_handle_get_resources at core/monitor.c:839
#9 ffi_call_SYSV at ../src/x86/sysv.S:65
#10 ffi_call at ../src/x86/ffi.c:411
#11 g_cclosure_marshal_generic at gclosure.c:1454
#12 g_type_iface_meta_marshal at gclosure.c:1021
Potential duplicate: bug 707996
Created attachment 791351 [details]
Created attachment 791352 [details]
Created attachment 791353 [details]
Created attachment 791354 [details]
Created attachment 791355 [details]
Created attachment 791356 [details]
Created attachment 791357 [details]
Created attachment 791358 [details]
Created attachment 791359 [details]
I tried to reproduce bug 1002055 on a different computer (amd graphics). Same media.
reason: Process /usr/bin/gnome-shell was killed by signal 5 (SIGTRAP)
reported_to: uReport: BTHASH=e0915aabecbda2a74620cb9e19240e509d1fe637
runlevel: N 5
Created attachment 791367 [details]
journal from the second attempt
Created attachment 791369 [details]
initial screen screenshot
Created attachment 791370 [details]
screen after cancelling welcome dialog
Reproduced on three different computers with two different USB media. Reproduced with dd, livecd-iso-to-disk and liveusb-creator.
Proposing as a blocker:
Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with at least one of the officially supported methods.
Oh, and the same issue is reproduced with CD in KVM, so this is not related to USB conversion at all.
Discussed at 2013-08-28 blocker review meeting . This is accepted as an Alpha blocker, because it violates the following F20 alpha release criterion for the 32bit desktop spin: "Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop." 
Can you please retest with that build http://koji.fedoraproject.org/koji/taskinfo?taskID=5873826 (one it is done) ?
I tried to build my own LiveCD, but there seem to be broken some dependencies. And even if I succeeded, RelEng probably uses a different build process. So ideally we need to have it included in the next TestCompose. However, we need a non-scratch build for that.
Please make a non-scratch build and switch this bug's status to MODIFIED. It will be picked up for the next TC.
Can you instead install the scratch rpm on the existing TC2 live cd?
Also, would it be possible to have the full coredump, or even better a gdb session where you try to look around at the level of meta_monitor_manager_handle_get_resources() and see if anything is obviously garbage?
(In reply to Kamil Páral from comment #18)
> I tried to build my own LiveCD, [...]
You can just do
yum install http://kojipkgs.fedoraproject.org//work/tasks/3828/5873828/mutter-3.9.90-2.fc20.x86_64.rpm
And restart your session.
Created attachment 792218 [details]
coredump with mutter-3.9.90-2.fc20
(In reply to Giovanni Campagna from comment #19)
> Can you instead install the scratch rpm on the existing TC2 live cd?
Good idea. I did, restarted gdm, but it did not help, still the same screen.
> Also, would it be possible to have the full coredump,
Attached, using the new mutter.
> or even better a gdb
> session where you try to look around at the level of
> meta_monitor_manager_handle_get_resources() and see if anything is obviously
I'm afraid I don't have the required gdb skills. Please do try it, the image is here:
Just want to tell that the new mutter-3.9.90-2.fc20.x86_64.rpm did it for me. May be another bug but I had the same effects like Kamil.
My system is a HP 5750 with AMD dual-core 64-bit CPU and AMD/ATI X1100/1150 mobile grafic chip. Before the new mutter I added radeon.modeset=0 to the kernel cmd-line and it works but the grafic was slow.
This is true for 64-bit. If I boot the 32-bit TC2-iso form usb flashdrive the new mutter-3.9.90-2.fc20.i686.rpm has no effect. With radeon.modeset=0 it works again.
I you need some logs please ask.
Oh I get the problem, this is 32 bits! That explains why it wasn't crashing for me.
Ok, so I just need to cast all the varargs to the right size...
*** Bug 1003160 has been marked as a duplicate of this bug. ***
Please fix this problem in .90 as I can't use GNOME after updating to this version for already 2 weeks.
(In reply to Christopher Meng from comment #25)
> Please fix this problem in .90 as I can't use GNOME after updating to this
> version for already 2 weeks.
.91 packages are being built right now:
Can anybody retry it with the latest builds?
(In reply to Jaroslav Reznik from comment #27)
> Can anybody retry it with the latest builds?
Looks good so far but I cant do a full update on my stick. There are still missing depends. Seems koji is still working on the rest the files.
# yum update mutter gnome-shell
and init 5 brings you to the normal screen now on i686 and is performant.
I will try a full update later.
Wow....I just tried .90 again with some gnome updates pushed yesterday.
Better and more smooth interface since last time I could login ;)
But still has crashes and network connection is not stable.
When I use botton on my laptop to enable/disable wifi, it crashed, but alt+tab switch could work so it didn't affect me.
[rpmaker@fab ~]$ rpm -qa|grep gnome-shell
[rpmaker@fab ~]$ rpm -qa|grep gnome
Created attachment 793718 [details]
gnome packages build 20130904 - 16:30 CEST
(In reply to Christopher Meng from comment #29)
> [rpmaker@fab ~]$ rpm -qa|grep gnome-shell
Looks like you are using the rawhide repos (fc21). IMO it should fc20 only.
That's my out from my harddisk install.
See attached file.
GNOME starts OK with F20 Alpha TC4 i386 Live: