Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
gnome-shell-3.24.3 coredump analysis
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
Arkhelion
Apprentice
Apprentice


Joined: 07 Sep 2010
Posts: 151
Location: France

PostPosted: Mon Apr 02, 2018 2:39 pm    Post subject: gnome-shell-3.24.3 coredump analysis Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14071

PostPosted: Tue Apr 03, 2018 1:52 am    Post subject: Reply with quote

Google: Gentoo Backtrace leads to Project:Quality Assurance/Backtraces - Gentoo Wiki. Follow the instructions there to prepare the system to create backtraces. Post back if you need more help, or when you have a backtrace you want someone to interpret.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5881

PostPosted: Tue Apr 03, 2018 2:00 am    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14071

PostPosted: Wed Apr 04, 2018 1:34 am    Post subject: Reply with quote

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
View user's profile Send private message
Arkhelion
Apprentice
Apprentice


Joined: 07 Sep 2010
Posts: 151
Location: France

PostPosted: Thu Apr 05, 2018 5:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14071

PostPosted: Fri Apr 06, 2018 1:57 am    Post subject: Reply with quote

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
View user's profile Send private message
Arkhelion
Apprentice
Apprentice


Joined: 07 Sep 2010
Posts: 151
Location: France

PostPosted: Mon Apr 16, 2018 10:38 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
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