| View previous topic :: View next topic |
| Author |
Message |
Arkhelion
Apprentice
Joined: 07 Sep 2010
Posts: 151
Location: France
|
 Posted: Mon Apr 02, 2018 2:39 pm Post subject: gnome-shell-3.24.3 coredump analysis |
 |
|
Hello everyone,
After a recent installation on a new computer, I'm having issues with gnome-shell. It regularly dies with a signal 6 ABRT (seems random, but occurs every 30-60min)
| Code: | gnome-session[2264]: gnome-session-binary[2264]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
gnome-session-binary[2264]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6 |
I tried to read coredumpctl but I don't have debug symbols and don't know how to get them at compile time, and even then, It certainly won't do me any good since I can't read a backtrace... but if any of you can, I'm more than willing to do whatever is needed so I can eventually find what's wrong and perhaps file a bug report if needed.
| Code: | $ sudo coredumpctl -1 gdb
PID: 2338 (gnome-shell)
UID: 1000 (******)
GID: 1000 (******)
Signal: 6 (ABRT)
Timestamp: Mon 2018-04-02 15:43:58 CEST (31min ago)
Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
Control Group: /user.slice/user-1000.slice/session-1.scope
Unit: session-1.scope
Slice: user-1000.slice
Session: 1
Owner UID: 1000 (******)
Boot ID: fd95ba77e0ed4ff48a95eaf3db626d0a
Machine ID: ce993c03f0ee2544972f0fae5a994181
Hostname: ******
Storage: /var/lib/systemd/coredump/core.gnome-shell.1000.fd95ba77e0ed4ff48a95eaf3db626d0a.2338.1522676638000000.lz4
Message: Process 2338 (gnome-shell) of user 1000 dumped core.
GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
Copyright (C) 2017 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 2338]
[New LWP 2358]
[New LWP 2360]
[New LWP 2359]
[New LWP 2339]
[New LWP 2361]
[New LWP 2365]
[New LWP 2357]
[New LWP 2362]
[New LWP 2364]
[New LWP 2340]
[New LWP 2366]
[New LWP 2372]
[New LWP 2363]
[New LWP 2824]
[New LWP 4849]
[New LWP 2369]
[New LWP 2371]
[New LWP 2367]
[New LWP 2368]
[New LWP 2342]
[New LWP 2370]
[New LWP 2356]
[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 SIGABRT, Aborted.
#0 0x00007f6a0e46bf90 in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f6a1143e9c0 (LWP 2338))]
(gdb) thread apply all bt
Thread 23 (Thread 0x7f69e9fa3700 (LWP 2356)):
#0 0x00007f6a0e524cfd in poll () from /lib64/libc.so.6
#1 0x00007f6a0a5f8ed1 in ?? () from /usr/lib64/libpulse.so.0
#2 0x00007f6a0a5ea691 in pa_mainloop_poll () from /usr/lib64/libpulse.so.0
#3 0x00007f6a0a5ead2e in pa_mainloop_iterate () from /usr/lib64/libpulse.so.0
#4 0x00007f6a0a5eade0 in pa_mainloop_run () from /usr/lib64/libpulse.so.0
#5 0x00007f6a0a5f8e19 in ?? () from /usr/lib64/libpulse.so.0
#6 0x00007f6a003b5538 in ?? () from /usr/lib64/pulseaudio/libpulsecommon-11.1.so
#7 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 22 (Thread 0x7f69e9196700 (LWP 2370)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 21 (Thread 0x7f69eabb3700 (LWP 2342)):
#0 0x00007f6a0e524cfd in poll () from /lib64/libc.so.6
#1 0x00007f6a0ea50906 in ?? () from /usr/lib64/libglib-2.0.so.0
#2 0x00007f6a0ea50a1c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3 0x00007f69eabbb4fd in ?? () from /usr/lib64/gio/modules/libdconfsettings.so
#4 0x00007f6a0ea78175 in ?? () from /usr/lib64/libglib-2.0.so.0
#5 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#6 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 20 (Thread 0x7f69e9298700 (LWP 2368)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 19 (Thread 0x7f69e9319700 (LWP 2367)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 18 (Thread 0x7f69e9115700 (LWP 2371)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 17 (Thread 0x7f69e9217700 (LWP 2369)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 16 (Thread 0x7f697c29f700 (LWP 4849)):
#0 0x00007f6a0e52ac69 in syscall () from /lib64/libc.so.6
#1 0x00007f6a0ea963ea in g_cond_wait_until () from /usr/lib64/libglib-2.0.so.0
#2 0x00007f6a0ea24ee9 in ?? () from /usr/lib64/libglib-2.0.so.0
#3 0x00007f6a0ea2550c in g_async_queue_timeout_pop () from /usr/lib64/libglib-2.0.so.0
#4 0x00007f6a0ea78c3d in ?? () from /usr/lib64/libglib-2.0.so.0
#5 0x00007f6a0ea78175 in ?? () from /usr/lib64/libglib-2.0.so.0
#6 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#7 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 15 (Thread 0x7f695bbff700 (LWP 2824)):
#0 0x00007f6a0e52ac69 in syscall () from /lib64/libc.so.6
#1 0x00007f6a0ea962cf in g_cond_wait () from /usr/lib64/libglib-2.0.so.0
#2 0x00007f6a0bc7ff9d in ?? () from /usr/lib64/mutter/libmutter-cogl-0.so
#3 0x00007f6a0ea78175 in ?? () from /usr/lib64/libglib-2.0.so.0
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 14 (Thread 0x7f69e951d700 (LWP 2363)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 13 (Thread 0x7f69e9094700 (LWP 2372)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 12 (Thread 0x7f69e939a700 (LWP 2366)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 11 (Thread 0x7f69ebfff700 (LWP 2340)):
#0 0x00007f6a0e524cfd in poll () from /lib64/libc.so.6
#1 0x00007f6a0ea50906 in ?? () from /usr/lib64/libglib-2.0.so.0
#2 0x00007f6a0ea50c92 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#3 0x00007f6a0f038146 in ?? () from /usr/lib64/libgio-2.0.so.0
#4 0x00007f6a0ea78175 in ?? () from /usr/lib64/libglib-2.0.so.0
#5 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#6 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 10 (Thread 0x7f69e949c700 (LWP 2364)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 9 (Thread 0x7f69e959e700 (LWP 2362)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 8 (Thread 0x7f69f00d3700 (LWP 2357)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 7 (Thread 0x7f69e941b700 (LWP 2365)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7f69e961f700 (LWP 2361)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f69f3a51700 (LWP 2339)):
#0 0x00007f6a0e524cfd in poll () from /lib64/libc.so.6
#1 0x00007f6a0ea50906 in ?? () from /usr/lib64/libglib-2.0.so.0
#2 0x00007f6a0ea50a1c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3 0x00007f6a0ea50a61 in ?? () from /usr/lib64/libglib-2.0.so.0
#4 0x00007f6a0ea78175 in ?? () from /usr/lib64/libglib-2.0.so.0
#5 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#6 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f69e9721700 (LWP 2359)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f69e96a0700 (LWP 2360)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f69e97a2700 (LWP 2358)):
#0 0x00007f6a0e7f4856 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f6a01902470 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#2 0x00007f6a095f1b6f in ?? () from /usr/lib64/libmozjs-38.so
#3 0x00007f6a01907d1c in ?? () from /usr/lib64/libnspr4.so
#4 0x00007f6a0e7ed8e7 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f6a0e53009f in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f6a1143e9c0 (LWP 2338)):
#0 0x00007f6a0e46bf90 in raise () from /lib64/libc.so.6
#1 0x00007f6a0e46dc5a in abort () from /lib64/libc.so.6
#2 0x00007f6a0e4aeb00 in ?? () from /lib64/libc.so.6
#3 0x00007f6a0e543767 in __fortify_fail () from /lib64/libc.so.6
#4 0x00007f6a0e540ec0 in __chk_fail () from /lib64/libc.so.6
#5 0x00007f6a0e54362e in __fdelt_warn () from /lib64/libc.so.6
#6 0x00007f6a0ea9812a in g_spawn_sync () from /usr/lib64/libglib-2.0.so.0
#7 0x00007f6a0ea98756 in g_spawn_command_line_sync () from /usr/lib64/libglib-2.0.so.0
#8 0x00007f6a09cfd008 in ffi_call_unix64 () from /usr/lib64/libffi.so.6
#9 0x00007f6a09cfca6a in ffi_call () from /usr/lib64/libffi.so.6
#10 0x00007f6a10935d3f in ?? () from /usr/lib64/libgjs.so.0
#11 0x00007f6a109373f4 in ?? () from /usr/lib64/libgjs.so.0
#12 0x00007f69f0050f85 in ?? ()
#13 0x00007ffc9b0350d0 in ?? ()
#14 0x00007ffc9b0350c8 in ?? ()
#15 0x0000000000000008 in ?? ()
#16 0x0000000000000000 in ?? () |
So if you know how to get something relevant from this, it'd be very kind to offer me some guidance.
Thanks a lot
_________________
Arkhelion |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21622
|
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Apr 03, 2018 2:00 am Post subject: |
|
|
| I'd say it's either in the top or bottom thread: pulseaudio or javascript code. Maybe both? What shell extensions have you installed/enabled? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21622
|
| Posted: Wed Apr 04, 2018 1:34 am Post subject: |
|
|
The bottom thread looks extremely suspicious. g_spawn_sync called fdelt_warn, which proceeded to kill the program due to a fortification failure. Based on the location of the declaration of fdelt_warn and its surrounding commentary in glibc, I think this is triggered when the program tries to add a file descriptor that glibc believes is out of range. If not trapped like this, it would have caused memory corruption.
OP: what ulimit is applied to gnome-shell? Once you get working debug symbols, please switch to frame #6 in thread #1 and show the output of info locals. |
|
| Back to top |
|
|
Arkhelion
Apprentice
Joined: 07 Sep 2010
Posts: 151
Location: France
|
| Posted: Thu Apr 05, 2018 5:12 pm Post subject: |
|
|
First of all, thanks for your answers.
| Ant P. wrote: | | I'd say it's either in the top or bottom thread: pulseaudio or javascript code. Maybe both? What shell extensions have you installed/enabled? |
I kinda narrowed it down to this extension (disabling it seems to stop the crashes or at least to make them a lot less frequent) :
https://extensions.gnome.org/extension/120/system-monitor/
But it could still be some bug in gnome-shell that's just boosted by this extension.
| Code: | [...]
Fri 2018-03-30 16:31:06 CEST 20199 1000 1000 6 present /usr/bin/gnome-shell
Fri 2018-03-30 17:11:23 CEST 507 1000 1000 6 present /usr/bin/gnome-shell
Fri 2018-03-30 17:51:40 CEST 10438 1000 1000 6 present /usr/bin/gnome-shell
Fri 2018-03-30 18:31:57 CEST 22678 1000 1000 6 present /usr/bin/gnome-shell
Fri 2018-03-30 23:37:55 CEST 1422 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 00:17:58 CEST 9042 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 09:17:34 CEST 16072 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 09:57:52 CEST 24055 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 10:39:42 CEST 31625 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 11:34:08 CEST 5596 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 12:14:25 CEST 11873 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 22:14:47 CEST 16994 1000 1000 6 present /usr/bin/gnome-shell
Sat 2018-03-31 23:48:12 CEST 23672 1000 1000 6 present /usr/bin/gnome-shell
Sun 2018-04-01 00:36:39 CEST 31694 1000 1000 6 present /usr/bin/gnome-shell
Sun 2018-04-01 09:35:29 CEST 4563 1000 1000 6 present /usr/bin/gnome-shell
Sun 2018-04-01 10:15:49 CEST 10648 1000 1000 6 present /usr/bin/gnome-shell
Sun 2018-04-01 20:02:52 CEST 16738 1000 1000 6 present /usr/bin/gnome-shell
Sun 2018-04-01 23:41:40 CEST 22692 1000 1000 6 present /usr/bin/gnome-shell
Mon 2018-04-02 00:21:59 CEST 29598 1000 1000 6 present /usr/bin/gnome-shell
Mon 2018-04-02 01:02:15 CEST 2551 1000 1000 6 present /usr/bin/gnome-shell
Mon 2018-04-02 13:21:58 CEST 4830 1000 1000 11 present /usr/bin/totem
Mon 2018-04-02 15:43:59 CEST 2338 1000 1000 6 present /usr/bin/gnome-shell
Wed 2018-04-04 00:45:08 CEST 13637 250 250 6 present /var/tmp/portage/dev-vcs/rcs-5.9.3/work/rcs-5.9.3/conftest
Wed 2018-04-04 00:45:24 CEST 19358 250 250 7 present /var/tmp/portage/dev-vcs/rcs-5.9.3/work/rcs-5.9.3/conftest |
| Hu wrote: | The bottom thread looks extremely suspicious. g_spawn_sync called fdelt_warn, which proceeded to kill the program due to a fortification failure. Based on the location of the declaration of fdelt_warn and its surrounding commentary in glibc, I think this is triggered when the program tries to add a file descriptor that glibc believes is out of range. If not trapped like this, it would have caused memory corruption.
OP: what ulimit is applied to gnome-shell? Once you get working debug symbols, please switch to frame #6 in thread #1 and show the output of info locals. |
I followed your previous link and added -gddb in CFLAGS and split-debug in FEATURES. In order to go faster I only rebuilt dev-libs/glib, sys-libs/glibc, dev-libs/libffi and dev-libs/gjs, as per the libraries seen in thread 1 (tell me if more is needed), plus gnome-base/gnome-shell, just in case, since gdb complained about missing debug symbols in that one. gdb seems a bit more verbose now.
Thread 1 backtrace :
| Code: | [Current thread is 1 (Thread 0x7f6a1143e9c0 (LWP 2338))]
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f6a0e46dc5a in __GI_abort () at abort.c:89
#2 0x00007f6a0e4aeb00 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f6a0e5b121d "*** %s ***: %s terminated\n")
at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007f6a0e543767 in __GI___fortify_fail (msg=msg@entry=0x7f6a0e5b11b4 "buffer overflow detected") at fortify_fail.c:30
#4 0x00007f6a0e540ec0 in __GI___chk_fail () at chk_fail.c:28
#5 0x00007f6a0e54362e in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:25
#6 0x00007f6a0ea9812a in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
standard_output=0x7ffc9b034b88, standard_error=0x7ffc9b034b90, exit_status=0x7ffc9b034b98, error=0x7ffc9b034d50)
at /var/tmp/portage/dev-libs/glib-2.52.3/work/glib-2.52.3/glib/gspawn.c:332
#7 0x00007f6a0ea98756 in g_spawn_command_line_sync (command_line=<optimized out>, standard_output=0x7ffc9b034b88,
standard_error=0x7ffc9b034b90, exit_status=0x7ffc9b034b98, error=0x7ffc9b034d50)
at /var/tmp/portage/dev-libs/glib-2.52.3/work/glib-2.52.3/glib/gspawn.c:725
#8 0x00007f6a09cfd008 in ffi_call_unix64 () at /var/tmp/portage/dev-libs/libffi-3.2.1/work/libffi-3.2.1/src/x86/unix64.S:76
#9 0x00007f6a09cfca6a in ffi_call (cif=cif@entry=0x562fe8672598, fn=<optimized out>, rvalue=<optimized out>, rvalue@entry=0x7ffc9b034d48,
avalue=avalue@entry=0x7ffc9b034bc0) at /var/tmp/portage/dev-libs/libffi-3.2.1/work/libffi-3.2.1/src/x86/ffi64.c:525
#10 0x00007f6a10935d3f in gjs_invoke_c_function (context=context@entry=0x562fe69a6e60, function=function@entry=0x562fe8672580, obj=...,
obj@entry=..., args=..., js_rval=..., r_value=r_value@entry=0x0) at gi/function.cpp:1021
#11 0x00007f6a109373f4 in function_call (context=0x562fe69a6e60, js_argc=1, vp=0x7ffc9b0350f0) at gi/function.cpp:1341
#12 0x00007f69f0050f85 in ?? ()
#13 0x00007ffc9b0350d0 in ?? ()
#14 0x00007ffc9b0350c8 in ?? ()
#15 0x0000000000000008 in ?? ()
#16 0x0000000000000000 in ?? () |
frame 6 :
| Code: | (gdb) frame 6
#6 0x00007f6a0ea9812a in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
standard_output=0x7ffc9b034b88, standard_error=0x7ffc9b034b90, exit_status=0x7ffc9b034b98, error=0x7ffc9b034d50)
at /var/tmp/portage/dev-libs/glib-2.52.3/work/glib-2.52.3/glib/gspawn.c:332
332 in /var/tmp/portage/dev-libs/glib-2.52.3/work/glib-2.52.3/glib/gspawn.c
(gdb) info locals
__d = <optimized out>
outpipe = 1020
errpipe = 1027
pid = 9694
fds = {fds_bits = {0 <repeats 15 times>, 1152921504606846976}}
ret = 0
outstr = 0x562fe6930200
errstr = 0x562fe69ec2c0
failed = 0
status = 32618
__func__ = "g_spawn_sync" |
As per your question about ulimit :
| Code: | $ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 62981
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 512000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 62981
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited |
_________________
Arkhelion |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21622
|
| Posted: Fri Apr 06, 2018 1:57 am Post subject: |
|
|
| Arkhelion wrote: | | Code: | [Current thread is 1 (Thread 0x7f6a1143e9c0 (LWP 2338))]
(gdb) bt
#5 0x00007f6a0e54362e in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:25
#6 0x00007f6a0ea9812a in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
standard_output=0x7ffc9b034b88, standard_error=0x7ffc9b034b90, exit_status=0x7ffc9b034b98, error=0x7ffc9b034d50)
at /var/tmp/portage/dev-libs/glib-2.52.3/work/glib-2.52.3/glib/gspawn.c:332 |
frame 6 : | Code: | (gdb) frame 6
#6 0x00007f6a0ea9812a in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0,
flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0,
standard_output=0x7ffc9b034b88, standard_error=0x7ffc9b034b90, exit_status=0x7ffc9b034b98, error=0x7ffc9b034d50)
at /var/tmp/portage/dev-libs/glib-2.52.3/work/glib-2.52.3/glib/gspawn.c:332
332 in /var/tmp/portage/dev-libs/glib-2.52.3/work/glib-2.52.3/glib/gspawn.c
(gdb) info locals
outpipe = 1020
errpipe = 1027
fds = {fds_bits = {0 <repeats 15 times>, 1152921504606846976}} |
As per your question about ulimit : | Code: | | open files (-n) 512000 |
|
So this explains the crash, but not necessarily how you got to the crash.
fds is an fd_set consisting of some number of __fd_mask. __fd_mask is typedef to long, which is 64-bit for you. The gdb output tells us that there are 16 elements (in this case, 15 elements of 0, followed by one element that, if printed as hex instead of decimal would be 1000000000000000). That 1000000000000000 is consistent with having a single bit set. It is also the value that would be expected if outpipe had been successfully added to the fd_set. So the crash happened when glib tried to add errpipe to the fd_set. The crash is correct, because the fd_set can only represent descriptors with values [0, 1023], yet glib tried to add 1027. Memory corruption would have resulted if the program had not aborted.
You have an abnormally high ulimit, which allowed gnome-shell to get back a descriptor that cannot be represented in the fd_set. If you lower your ulimit -n to 1024, this specific crash will not happen. However, it is rather unlikely that gnome-shell would have such a high number descriptor open unless something had leaked all the lower numbered descriptors. Therefore, you probably have some buggy component running in gnome-shell that leaks descriptors. When enough leak, errpipe gets a value that is too large, causing this abort. Fix the descriptor leak and the problem should stop. If you only lower your ulimit, but do not fix the descriptor leak, you are probably only trading one failure mode for another. Expect something to break. |
|
| Back to top |
|
|
Arkhelion
Apprentice
Joined: 07 Sep 2010
Posts: 151
Location: France
|
| Posted: Mon Apr 16, 2018 10:38 pm Post subject: |
|
|
Hi,
thank you for your crystal clear answer about the crash. As per the reason of the crash I'm now positive it was due to this extension (no more crash since removal) :
https://extensions.gnome.org/extension/120/system-monitor/
The descriptor leak must be in that component (or an interaction between this component and another). I mostly used it to monitor CPU Temp, so I replaced it with Freon. I can't see RAM usage or ETH bandwidth but it might be enough in the long run to just monitor CPU Temp.
About your comment considering ulimit, I don't remember changing it, the only reason I can think of is that some emerge did ask me to change something (this install is quite recent) or it might be default in systemd stage3 tarball.
_________________
Arkhelion |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
