Bug 1101312 - gnome-shell 3.10.4-4 crashes with SIGTRAP when launched
Summary: gnome-shell 3.10.4-4 crashes with SIGTRAP when launched
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 20
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1083500
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-26 19:00 UTC by Bernardo Donadio
Modified: 2014-06-04 19:20 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-04 19:20:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
gdb stacktrace of crash (25.24 KB, text/plain)
2014-05-31 19:22 UTC, Bernardo Donadio
no flags Details
log messages from journalctl for a ok session started via 'startx' (4.31 KB, text/plain)
2014-05-31 19:27 UTC, Michal Jaegermann
no flags Details
log messages from journalctl for a crashed gnome-session (9.23 KB, text/plain)
2014-05-31 19:29 UTC, Michal Jaegermann
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1083500 0 unspecified CLOSED Crosshairs Are Broken 2021-02-22 00:41:40 UTC

Description Bernardo Donadio 2014-05-26 19:00:26 UTC
Description of problem:
After a update from gnome-shell 3.10.4-2@updates to 3.10.4-4@updates-testing, gnome-shell crashes with SIGTRAP showing a "Oh no something has gone wrong" screen, but only if launched by gdm. Mannualy logging in the VT and running a startx works normally.

I confirm this problem *disappears* after downgrading to gnome-shell 3.10.4-2 (already tried going back and forward on package versions, behaviour is consistent). Already tried wiping gnome configs, still crashes.

I'm unsure which log should I attach. No relevant info is shown in .xsession-errors, neither at Xorg.0.log.

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

How reproducible:
Always if gnome-shell is started from gdm. Non-reproducible if started from startx.

Steps to Reproduce:
1. Upgrade to gnome-shell 3.10.4-4
2. Login trough GDM into gnome-shell

Actual results:
A "Oh no something has gone wrong passing" screen is displayed, no mouse icon is show, altough buttons do react upon mouse hovering.

Expected results:
A working gnome-shell environment.

Additional info:
I'm using a three-monitor setup, with two graphic cards. Graphic driver is radeon. Kernel 3.15.0-0.rc5.git4.1.fc21.x86_64. Rest of the system is with FC20 packages.

Comment 1 Michal Jaegermann 2014-05-30 20:17:18 UTC
Launching by gdm does not seem to be relevant.  Starting via lightdm has the same effects.  On a machine caught by this I got the following in logs:

[   80.720607] traps: gnome-shell[2166] trap int3 ip:316dc504e9 sp:7fff529d64a0 error:0
[   81.542563] traps: gnome-shell[2240] trap int3 ip:316dc504e9 sp:7fff116d3310 error:0
[  822.021392] traps: gnome-shell[3269] trap int3 ip:316dc504e9 sp:7fff586017b0 error:0
[  822.930987] traps: gnome-shell[3326] trap int3 ip:316dc504e9 sp:7fff9a93e310 error:0

The first two are from gnome-shell-3.10.4-4.fc20.x86_64; two which follow are from an attempt to downgrade to gnome-shell-3.10.4-3.fc20.x86_64.  Only backing down to gnome-shell-3.10.4-2.fc20.x86_64 makes this to work again.

In this case this is as plain setup as it gets.  One graphic card and one monitor.

Comment 2 Michal Jaegermann 2014-05-31 01:55:19 UTC
Just in case on a machine I have a gnome-shell which refuses to start I removed _all_ gnome-shell extensions but this did not help at all.  In many gnome-shell crashes once I got in logs the following:

[ 1717.422050] traps: gnome-shell[3854] trap int3 ip:3cda8504e9 sp:7fffc67f1660 error:0
[ 1717.439453] gnome-settings-[3830]: segfault at 18 ip 000000396941be59 sp 00007fff32ef6d60 error 4 in libgnome-desktop-3.so.8.0.0[3969400000+40000]
[ 1719.733770] traps: gnome-shell[3934] trap int3 ip:3cda8504e9 sp:7fff5e1ba320 error:0

I also tried to follow https://wiki.gnome.org/Projects/GnomeShell/Debugging after loading gnome-shell-debuginfo.  Clearly I could only attach gdb to a crashed gnome-shell. Following "Acquiring a backtrace" instruction from this page I got this:

(gdb) t a a bt

Thread 4 (Thread 0x7fee14a72700 (LWP 4617)):
#0  0x0000003cd80ea9dd in poll () from /lib64/libc.so.6
#1  0x0000003cda8495b4 in g_main_context_iterate.isra ()
   from /lib64/libglib-2.0.so.0
#2  0x0000003cda849a3a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x00000034f3ad0376 in gdbus_shared_thread_func ()
   from /lib64/libgio-2.0.so.0
#4  0x0000003cda86ea45 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x0000003cd8c07f33 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003cd80f4ded in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7fee0ffff700 (LWP 4618)):
#0  0x0000003cd80ea9dd in poll () from /lib64/libc.so.6
#1  0x0000003cda8495b4 in g_main_context_iterate.isra ()
   from /lib64/libglib-2.0.so.0
#2  0x0000003cda8496dc in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#3  0x00007fee14042b7d in dconf_gdbus_worker_thread ()
   from /usr/lib64/gio/modules/libdconfsettings.so
#4  0x0000003cda86ea45 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x0000003cd8c07f33 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003cd80f4ded in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fee0effd700 (LWP 4620)):
#0  0x0000003cd80ea9dd in poll () from /lib64/libc.so.6
#1  0x0000003cda8495b4 in g_main_context_iterate.isra ()
   from /lib64/libglib-2.0.so.0
#2  0x0000003cda8496dc in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#3  0x0000003cda849729 in glib_worker_main () from /lib64/libglib-2.0.so.0
#4  0x0000003cda86ea45 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x0000003cd8c07f33 in start_thread () from /lib64/libpthread.so.0
#6  0x0000003cd80f4ded in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fee14a73a80 (LWP 4449)):
#0  0x0000003cd80ea9dd in poll () from /lib64/libc.so.6
#1  0x0000003cda8495b4 in g_main_context_iterate.isra ()
   from /lib64/libglib-2.0.so.0
#2  0x0000003cda849a3a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x0000000000409400 in main ()
(gdb) call gjs_dumpstack ()
No symbol table is loaded.  Use the "file" command.

What is expected from 'gjs_dumpstack ()' and how to get that I have no idea.

Downgrading to gnome-shell-3.10.4-2.fc20 immediately fixes the whole mess.

Note: if further information from me is required I am going away in few days and after that I can run further tests only in the end of July.

Comment 3 Bernardo Donadio 2014-05-31 05:29:12 UTC
(In reply to Michal Jaegermann from comment #2)
> Note: if further information from me is required I am going away in few days
> and after that I can run further tests only in the end of July.

Michal, do you also get the same behaviour when lauching the gnome-session from startx? I have no idea why, but this problem does not happens when I launch it from startx.

Comment 4 Bernardo Donadio 2014-05-31 19:22:00 UTC
Created attachment 901119 [details]
gdb stacktrace of crash

Here I dumped the stacktrace of the crash, using gnome-shell-3.10.4-3 (which is the first patch that created the bug). It's definitely linked to the magnifying glass feature.

Comment 5 Michal Jaegermann 2014-05-31 19:26:23 UTC
(In reply to Bernardo Donadio from comment #3)

> Michal, do you also get the same behaviour when lauching the gnome-session
> from startx? I have no idea why, but this problem does not happens when I
> launch it from startx.

Indeed, you are right.  Running startx from a level 3 brings up what looks like a normal desktop session.  Still in an output of 'journalctl -xb' I see
entries like:

gnome-session[2182]: (gnome-settings-daemon:2335): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

There are also entries like this one "Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1800008 (gnome-twea)", but that seems to be hardly relevant as I was getting the same gnome-session crashes when gnome-tweak-tool was not even installed.  It is not configured to autostart anyway.

When doing that from a level 5, with a display-manager.service running, I can find these:

May 31 13:03:12 ... gnome-session[5131]: Window manager warning: Log level 6: AT-SPI: COuldn't connect to accessibility bus. Is at-spi-bus-launcher running?
May 31 13:03:12 ... kernel: traps: gnome-shell[5186] trap int3 ip:3cda8504e9 sp:7fff04d5de20 error:0

Well, yes, at-spi-bus-launcher is running.  It is a process 4867 at my current layout.  There is more failed assertions in the second case then in the first one.

I attach relevant fragments of journalctl output for a session started with startx and for a bomb.

Comment 6 Michal Jaegermann 2014-05-31 19:27:56 UTC
Created attachment 901120 [details]
log messages from journalctl for a ok session started via 'startx'

Comment 7 Michal Jaegermann 2014-05-31 19:29:12 UTC
Created attachment 901128 [details]
log messages from journalctl for a crashed gnome-session

Comment 8 Michal Jaegermann 2014-05-31 20:48:43 UTC
This reminds me.  There is another bug 1053850 with a gnome-shell crash after "AT-SPI: COuldn't connect to accessibility bus. Is at-spi-bus-launcher running?". Also "traps: gnome-shell[9628] trap int3 ip:31b3a504e9 sp:7fff1b409b60" looks familar (at least "504e9").  That other bug still sits as NEW.  Another one is bug 1051559.

Comment 9 Bernardo Donadio 2014-05-31 21:25:53 UTC
Should this be filled upstream?

Comment 10 Florian Müllner 2014-06-04 19:20:59 UTC
This should be fixed in gnome-shell-3.10.4-5 now, closing.


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