Created attachment 469348 [details] emerge --info Hello, Since the stable upgrade sunday, two out of three of my computers are having "trouble", gnome-shell (3.22) crashes and thus renders the system unusable. Compiling with a pre-sunday portage tree (so gnome 3.20) makes the system works again. emerge --info included, journalctl -b -a with the gdm debug activated included too. X/xorg starts with no trouble, I /do/ have a working X environment, but gnome/gdm doesn't. avril 06 18:55:06 gentoo.local.tld gnome-shell[4037]: The Clutter backend is not a X11 backend avril 06 18:55:06 gentoo.local.tld kernel: gnome-shell[4037]: segfault at 10 ip 00007fe5f192ae84 sp 00007ffedb632830 error 4 in libmutter.so.0.0.0[7fe5f18e1000+df000] avril 06 18:55:06 gentoo.local.tld gnome-shell[4042]: The Clutter backend is not a X11 backend avril 06 18:55:06 gentoo.local.tld kernel: gnome-shell[4042]: segfault at 10 ip 00007f13e3f5fe84 sp 00007ffdc76de0f0 error 4 in libmutter.so.0.0.0[7f13e3f16000+df000] avril 06 18:55:06 gentoo.local.tld gnome-session-binary[4016]: Unrecoverable failure in required component org.gnome.Shell.desktop avril 06 18:55:06 gentoo.local.tld kernel: gnome-session-f[4046]: segfault at 0 ip 00007fedc42f4c39 sp 00007ffc75f09690 error 4 in libgtk-3.so.0.2200.11[7fedc4012000+701000] I'm currently out of ideas...
Created attachment 469350 [details] journalctl -b -a journalctl -b -a of the "session": # systemctl start gdm # systemctl stop gdm
Output of emerge -1vp cogl clutter mutter gnome-shell gdm please
There you go: # emerge -1vp cogl clutter mutter gnome-shell gdm These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild R ] media-libs/cogl-1.22.2:1.0/20::gentoo USE="gles2 introspection kms opengl pango -debug -examples (-gstreamer) {-test} -wayland" VIDEO_CARDS="(-fglrx)" 0 KiB [ebuild R ] x11-wm/mutter-3.22.3::gentoo USE="introspection udev -debug -gles2 {-test} -wayland" INPUT_DEVICES="-wacom" 0 KiB [ebuild R ] media-libs/clutter-1.26.0:1.0::gentoo USE="X egl gtk introspection (-aqua) -debug -doc {-test} -wayland" 0 KiB [ebuild R ] gnome-base/gnome-shell-3.22.3-r1::gentoo USE="bluetooth browser-extension ibus networkmanager nsplugin (-openrc-force)" PYTHON_TARGETS="python3_4 (-python3_5)" 0 KiB [ebuild R ] gnome-base/gdm-3.22.3::gentoo USE="branding introspection ipv6 xinerama -accessibility -audit -fprint -plymouth (-selinux) -smartcard -tcpd {-test} -wayland" 0 KiB Total: 5 packages (5 reinstalls), Size of downloads: 0 KiB Thanks for having a look !
I don't see anything wrong with the USE flags, so I'm stumped. Any chance you are getting a core dump saved in coredumpctl and can get a backtrace via it?
If you have a doc/tuto which I can follow, I can try to do that, yes.
I presume you don't have some weird CLUTTER_BACKEND environment setting going on anywhere on your system? I think the clutter backend should be the GDK backend for gnome-shell, so it's odd that it's looking for a X11 backend. Also note that this is probably from mutter, not clutter, the clutter code got bundled in mutter, but other things than gnome-shell still using clutter use clutter directly still, not the bundled version (this bundling might already have happened in 3.20, I don't remember).
For starters, do you have anything for it in coredumpctl? If you just launch that, then at the end there should be an entry with the crash date/time for gnome-shell or something in there, hopefully with the second to last (before command line) column having a * for "core dump present"
No, no CLUTTER_BACKEND strange variable. No coredumps either, but I'll try again tomorrow (for some reason the core limit is 0, which might explain it). I'll go unlimited tomorrow and relaunch it, right now I cannot launch it: both screens are off and apparently it stops X from launching... ? # coredumpctl No coredumps found.
# ulimit -c unlimited # systemctl start gdm # dmesg (...) [61078.263597] gnome-shell[28782]: segfault at 10 ip 00007f45b13cde84 sp 00007ffdf9e17ea0 error 4 in libmutter.so.0.0.0[7f45b1384000+df000] [61078.370639] gnome-shell[28787]: segfault at 10 ip 00007ff7ecbf4e84 sp 00007ffc387bca90 error 4 in libmutter.so.0.0.0[7ff7ecbab000+df000] [61078.394810] gnome-session-f[28791]: segfault at 0 ip 00007f1244dbdc39 sp 00007ffd0af777a0 error 4 in libgtk-3.so.0.2200.11[7f1244adb000+701000] # coredumpctl No coredumps found. What am I missing ?
I need to figure this out myself too for a different crash debugging, but haven't gotten around to it. But maybe core dump limit is still 0 for the gdm user. I'd look into man limits.conf and /etc/security/limits.conf (or /etc/security/limits.d)
Though for me it seems to report it's unlimited, yet I don't have core dumps for my gdm crash thing (on first boot with wayland issue) without something else done, unless I'm checking wrong: su -s /bin/bash -c "ulimit -c" gdm unlimited
Ah, got them: # grep core /etc/security/limits.conf * soft core unlimited * hard core unlimited # cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e # systemctl start gdm # coredumpctl TIME PID UID GID SIG PRESENT EXE ven. 2017-04-07 12:10:04 CEST 5849 103 102 11 * /usr/bin/gnome-shell ven. 2017-04-07 12:10:04 CEST 5860 103 102 11 * /usr/libexec/gnome-session-failed ven. 2017-04-07 12:10:05 CEST 5855 103 102 11 * /usr/bin/gnome-shell # coredumpctl gdb 5849 PID: 5849 (gnome-shell) UID: 103 (gdm) GID: 102 (gdm) Signal: 11 (SEGV) Timestamp: ven. 2017-04-07 12:10:04 CEST (18min ago) Command Line: /usr/bin/gnome-shell Executable: /usr/bin/gnome-shell Control Group: /user.slice/user-103.slice/session-c3.scope Unit: session-c3.scope Slice: user-103.slice Session: c3 Owner UID: 103 (gdm) Boot ID: 26e5f368d9f745f282ae88870f86f487 Machine ID: a9a28078af1ff1eab63315a900001b09 Hostname: citron.cusae.com Coredump: /var/lib/systemd/coredump/core.gnome-shell.103.26e5f368d9f745f282ae88870f86f487.5849.1491559804000000.lz4 Message: Process 5849 (gnome-shell) of user 103 dumped core. GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/gnome-shell...(no debugging symbols found)...done. [New LWP 5849] [New LWP 5853] [New LWP 5851] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f2e2a65be84 in ?? () from /usr/lib64/libmutter.so.0 [Current thread is 1 (Thread 0x7f2e2bb8a9c0 (LWP 5849))] Unsure what to do next :)
thread apply all bt full
(gdb) thread apply all bt full Thread 3 (Thread 0x7f8fccd4a700 (LWP 4417)): #0 0x00007f8fe1002348 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8fcedf8e44 in ?? () from /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0 No symbol table info available. #2 0x00007f8fcdb16394 in ?? () from /usr/lib64/libnvidia-glcore.so.378.13 No symbol table info available. #3 0x00007f8fcedf812c in ?? () from /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0 No symbol table info available. #4 0x00007f8fe0ffc3c4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #5 0x00007f8fe0d4358d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 2 (Thread 0x7f8fcf886700 (LWP 4415)): #0 0x00007f8fe0d3a4ad in poll () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f8fe125b66c in ?? () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. #2 0x00007f8fe125b77c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. #3 0x00007f8fe125b7b9 in ?? () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. #4 0x00007f8fe1282c25 in ?? () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. #5 0x00007f8fe0ffc3c4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #6 0x00007f8fe0d4358d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7f8fe41399c0 (LWP 4413)): #0 0x00007f8fe2c0ae84 in ?? () from /usr/lib64/libmutter.so.0 No symbol table info available. #1 0x00007f8fe2c33687 in meta_init () from /usr/lib64/libmutter.so.0 No symbol table info available. #2 0x0000000000401f82 in main () No symbol table info available.
Can you please re-do all that after adding debug symbols to at least mutter and hitting up a fresh core dump that used the rebuilt mutter, so we'd get symbol information and more, instead of '??' there for Thread 1? Basically add -ggdb to CFLAGS and splitdebug (and potentially also compressdebug if interested) to FEATURES, e.g CFLAGS="O2 -pipe -march=native -ggdb" FEATURES="splitdebug compressdebug" If you want to get even better backtrace, then can also install debugedit package and add installsources to FEATURES too. https://wiki.gentoo.org/wiki/Debugging
To be sure Thread 2 isn't affecting anything there, might be good to just rebuild dev-libs/glib with debugging symbols too in one go. The given link tells how to do it per-package. Or you can just do it temporarily globally and later remove it again or use env vars on command line for emerge run or something.
Ok, here's a better one: Thread 3 (Thread 0x7fd55cb97700 (LWP 8754)): #0 0x00007fd56e04b4ad in poll () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fd56e56c66c in g_main_context_poll (priority=2147483647, n_fds=1, fds=0x7fd5580008e0, timeout=-1, context=0x1ba7130) at /var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/glib/gmain.c:4228 poll_func = 0x7fd56e57c960 <g_poll> #2 g_main_context_iterate (context=context@entry=0x1ba7130, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/glib/gmain.c:3924 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7fd5580008e0 #3 0x00007fd56e56c77c in g_main_context_iteration (context=0x1ba7130, may_block=may_block@entry=1) at /var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/glib/gmain.c:3990 retval = <optimized out> #4 0x00007fd56e56c7b9 in glib_worker_main (data=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/glib/gmain.c:5783 No locals. #5 0x00007fd56e593c25 in g_thread_proxy (data=0x1ba7400) at /var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/glib/gthread.c:784 thread = 0x1ba7400 #6 0x00007fd56e30d3c4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #7 0x00007fd56e05458d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 2 (Thread 0x7fd556005700 (LWP 8756)): #0 0x00007fd56e313348 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fd55c109e44 in ?? () from /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0 No symbol table info available. #2 0x00007fd556dd1394 in ?? () from /usr/lib64/libnvidia-glcore.so.378.13 No symbol table info available. #3 0x00007fd55c10912c in ?? () from /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0 No symbol table info available. #4 0x00007fd56e30d3c4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #5 0x00007fd56e05458d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7fd57144a9c0 (LWP 8752)): #0 x_event_source_new (backend=0x1baa0c0) at backends/x11/meta-backend-x11.c:414 x11 = <optimized out> source = 0x1bb08e0 x_source = 0x1bb08e0 #1 meta_backend_x11_post_init (backend=0x1baa0c0) at backends/x11/meta-backend-x11.c:461 x11 = <optimized out> major = 1851168091 minor = 32725 #2 0x00007fd56ff44687 in meta_init () at core/main.c:493 act = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0x0} empty_mask = {__val = {0 <repeats 16 times>}} compositor_type = META_COMPOSITOR_TYPE_X11 backend_type = META_BACKEND_TYPE_X11 #3 0x0000000000401f82 in main (argc=1, argv=0x7fff691cb0e8) at main.c:437 ctx = 0x1ba6b80 error = 0x0 ecode = <optimized out> sender = <optimized out>
I recompiled all (or almost, a few exceptions) my system with debug, nostrip, installsources, etc, you'll find attached the 3 backtraced core dumps corresponding to: desktop kernel: nvidia-modeset: Allocated GPU:0 (GPU-f93cfd7c-7b8b-3b7f-3c25-a3e6803bb101) @ PCI:0000:01:00.0 desktop gnome-shell[2405]: The Clutter backend is not a X11 backend desktop kernel: gnome-shell[2405]: segfault at 10 ip 00007f88b9f0fe84 sp 00007fffd99697b0 error 4 in libmutter.so.0.0.0[7f88b9ec6000+df000] desktop kernel: gnome-shell[2410]: segfault at 10 ip 00007f4ba1251e84 sp 00007fff8e2a3e50 error 4 in libmutter.so.0.0.0[7f4ba1208000+df000] desktop gnome-shell[2410]: The Clutter backend is not a X11 backend desktop gnome-session-binary[2384]: Unrecoverable failure in required component org.gnome.Shell.desktop desktop kernel: gnome-session-f[2414]: segfault at 0 ip 00007f720982bc39 sp 00007ffcfd0ecac0 error 4 in libgtk-3.so.0.2200.11[7f7209549000+701000] desktop kernel: nvidia-modeset: Freed GPU:0 (GPU-f93cfd7c-7b8b-3b7f-3c25-a3e6803bb101) @ PCI:0000:01:00.0 desktop kernel: nvidia-modeset: Allocated GPU:0 (GPU-f93cfd7c-7b8b-3b7f-3c25-a3e6803bb101) @ PCI:0000:01:00.0 desktop gnome-shell[2564]: The Clutter backend is not a X11 backend desktop kernel: gnome-shell[2564]: segfault at 10 ip 00007fe328ecfe84 sp 00007ffff28a0880 error 4 in libmutter.so.0.0.0[7fe328e86000+df000] desktop systemd-coredump[2569]: Process 2564 (gnome-shell) of user 103 dumped core. desktop kernel: gnome-shell[2570]: segfault at 10 ip 00007f8ccb3d1e84 sp 00007ffe109c4b70 error 4 in libmutter.so.0.0.0[7f8ccb388000+df000] desktop gnome-shell[2570]: The Clutter backend is not a X11 backend desktop gnome-session-binary[2543]: Unrecoverable failure in required component org.gnome.Shell.desktop desktop kernel: gnome-session-f[2575]: segfault at 0 ip 00007fddb59c3c39 sp 00007ffd8c9691e0 error 4 in libgtk-3.so.0.2200.11[7fddb56e1000+701000] desktop systemd-coredump[2579]: Process 2575 (gnome-session-f) of user 103 dumped core. desktop systemd-coredump[2574]: Process 2570 (gnome-shell) of user 103 dumped core. desktop gnome-session-binary[2543]: Entering running state desktop gnome-settings-[2576]: Name taken or bus went away - shutting down desktop kernel: nvidia-modeset: Freed GPU:0 (GPU-f93cfd7c-7b8b-3b7f-3c25-a3e6803bb101) @ PCI:0000:01:00.0
Created attachment 469568 [details] first gnome-shell core
Created attachment 469570 [details] second gnome-sessions-failed core
Created attachment 469572 [details] second gnome-shell coredump
I've bumped mutter to 3.22.4, but I doubt it helps any for this case here. But worth a try. Otherwise I need to jump in and read the surrounding code and so on. I need to do that anyways for bug 613222, but haven't managed to get the dedicated time for it yet.
Mart, I opened a bug directly upstream at gnome: https://bugzilla.gnome.org/show_bug.cgi?id=774021 It seems for them it's the result of a bad linking, gnome-shell shouldn't link to all that libraries. Does that ring a bell to you ?
Not really, $ ldd /usr/bin/gnome-shell |grep -E "(cog|mutter)" libmutter-cogl-pango.so => /usr/lib64/mutter/libmutter-cogl-pango.so (0x00007f5b38f39000) libmutter.so.0 => /usr/lib64/libmutter.so.0 (0x00007f5b38599000) libmutter-clutter-1.0.so => /usr/lib64/mutter/libmutter-clutter-1.0.so (0x00007f5b37926000) libmutter-cogl.so => /usr/lib64/mutter/libmutter-cogl.so (0x00007f5b3404a000) libmutter-cogl-path.so => /usr/lib64/mutter/libmutter-cogl-path.so (0x00007f5b2ce5e000) Can you check/attach lddtree /usr/bin/gnome-shell ? lddtree comes from pax-utils if you don't have it
Created attachment 469944 [details] lddtree /usr/bin/gnome-shell output attached, it's a bit verbose :)
Mart, on my working desktop, gnome-shell 3.20: cusae@citron ~ $ ldd /usr/bin/gnome-shell |grep -E "(cog|mutter)" libmutter.so.0 => /usr/lib64/libmutter.so.0 (0x00007f33480cc000) libcogl-pango.so.20 => /usr/lib64/libcogl-pango.so.20 (0x00007f3347032000) libcogl.so.20 => /usr/lib64/libcogl.so.20 (0x00007f33442fc000) libcogl-path.so.20 => /usr/lib64/libcogl-path.so.20 (0x00007f333daef000) On the non working one, gnome-shell 3.22: # ldd /usr/bin/gnome-shell |grep -E "(cog|mutter)" libmutter-cogl-pango.so => /usr/lib64/mutter/libmutter-cogl-pango.so (0x00007f87eae43000) libmutter.so.0 => /usr/lib64/libmutter.so.0 (0x00007f87ea713000) libcogl.so.20 => /usr/lib64/libcogl.so.20 (0x00007f87e84c9000) libmutter-clutter-1.0.so => /usr/lib64/mutter/libmutter-clutter-1.0.so (0x00007f87e679f000) libmutter-cogl.so => /usr/lib64/mutter/libmutter-cogl.so (0x00007f87e3839000) libcogl-path.so.20 => /usr/lib64/libcogl-path.so.20 (0x00007f87e086e000) libcogl-pango.so.20 => /usr/lib64/libcogl-pango.so.20 (0x00007f87e0665000) libmutter-cogl-path.so => /usr/lib64/mutter/libmutter-cogl-path.so (0x00007f87dc679000)
Ok, so for some reason gnome-shell is directly linking to libclutter and libgnome-shell.so is directly linking to libgnome-shell.so I think I need a full build.log to compare to a properly linking one from myself. As build itself is successful, you could for example get it via FEATURES="keeptemp keepwork" emerge -1v gnome-shell and then attaching /var/tmp/portage/gnome-base/gnome-shell-3.22.3-r1/temp/build.log Only keeptemp might be succificient as well. It'll leave all that stuff behind, so might want to clean up sometime after.
(In reply to Mart Raudsepp from comment #27) > Ok, so for some reason gnome-shell is directly linking to libclutter and > libgnome-shell.so is directly linking to libgnome-shell.so err, libgnome-shell.so is directly linking to libcogl.so.20 But yeah, you got the idea :) And yes, I saw the ldd grep from gnome bugzilla, while lddtree attachment showed me if the non-mutter clutter/cogl are linked to directly or indirectly
Created attachment 469946 [details] gnome-shell build.log FEATURES="keeptemp keepwork" emerge -1v gnome-shell /var/tmp/portage/gnome-base/gnome-shell-3.22.3-r1/temp/build.log enclosed
>>> It appears that 'gnome-shell-3.22.3-r1' is already setup; skipping. >>> Remove '/var/tmp/portage/gnome-base/gnome-shell-3.22.3-r1/.setuped' to force setup. >>> WORKDIR is up-to-date, keeping... Can you give me a clean build.log that isn't ctrl+C'ed and then continued? It's messing up my diffing a bit. Just if you're around to do it within 15 minutes, otherwise I'll probably have bitten through it already anyways :) To do so, clean up /var/tmp/portage/gnome-base/gnome-shell-3.22.3-r1 (careful rm -rf or so) and re-do
Created attachment 469948 [details] gnome-shell clean build.log cleaner build.log attached
Okay, I just checked the difference between the working and non-working desktops, with the /same/ gnome-shell version (3.22.3-r1): working one: # ldd /usr/bin/gnome-shell|grep -E "(cogl|mutt)" | sort libmutter-clutter-1.0.so => /usr/lib64/mutter/libmutter-clutter-1.0.so (0x00007f9137788000) libmutter-cogl-pango.so => /usr/lib64/mutter/libmutter-cogl-pango.so (0x00007f9138d4e000) libmutter-cogl-path.so => /usr/lib64/mutter/libmutter-cogl-path.so (0x00007f912ded6000) libmutter-cogl.so => /usr/lib64/mutter/libmutter-cogl.so (0x00007f9134135000) libmutter.so.0 => /usr/lib64/libmutter.so.0 (0x00007f91383ee000) Non working one: # ldd /usr/bin/gnome-shell|grep -E "(cogl|mutt)" | sort libcogl-pango.so.20 => /usr/lib64/libcogl-pango.so.20 (0x00007f893fd06000) libcogl-path.so.20 => /usr/lib64/libcogl-path.so.20 (0x00007f893ff0f000) libcogl.so.20 => /usr/lib64/libcogl.so.20 (0x00007f8947b6a000) libmutter-clutter-1.0.so => /usr/lib64/mutter/libmutter-clutter-1.0.so (0x00007f8945e40000) libmutter-cogl-pango.so => /usr/lib64/mutter/libmutter-cogl-pango.so (0x00007f894a4e4000) libmutter-cogl-path.so => /usr/lib64/mutter/libmutter-cogl-path.so (0x00007f893bd1a000) libmutter-cogl.so => /usr/lib64/mutter/libmutter-cogl.so (0x00007f8942eda000) libmutter.so.0 => /usr/lib64/libmutter.so.0 (0x00007f8949db4000) Definetely some linker breakage here, but question is, why ? I'm trying to find a few culprits, but so far, nothing... I tried with networkmanager use flag on or off, doesn't change a thing.
I think I found my trouble... (chroot) citron lib64 # ls -la libmutter.* -rwxr-xr-x 1 root root 1464 2 nov. 2015 libmutter.la (despite numerous rebuilds those last 2 weeks) libmutter.la:dependency_libs=' -lupower-glib -lgnome-desktop-3 -lXcursor -lxkbfile -lxkbcommon-x11 -lxkbcommon -lXrender -lX11-xcb -lxcb-randr -lxcb-render -lxcb -lstartup-notification-1 -lcanberra-gtk3 -lcanberra -lgtk-3 -lgirepository-1.0 -lSM -lICE -lXinerama -lm -lclutter-1.0 -lcogl-path -latk-1.0 -lcogl-pango -lcogl -lgmodule-2.0 -lEGL -lXrandr -ljson-glib-1.0 -lgio-2.0 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lX11 -lXext -lXdamage -lXfixes -lXcomposite -lXi -ldrm -lsystemd -linput -lgudev-1.0 -lgobject-2.0 -lglib-2.0 -lgbm' AFAIK, it was an old local build with a patch for some strange artefacts with nvidia... Apparently, it left a @#! file. Verifying now.
Yeah, that'd do it. System mutter we filter out all the *.la files to not be installed, so it was a stray file that gnome-shell linking would have picked up and potentially used somewhere when found
So INVALID I guess? :(
Just finished testing on the second desktop, the old .la file was definitely the problem... Sorry for all the lost time :( It can of course be closed as INVALID with "stupid user" as subcomment. I did learn a great deal on debugging this stuff though, so for me, all is not completely lost :/
Ok, and how to get gdm user to insert stuff into coredumpctl will help me in my debugging as well for bug 613222
