Unfortunately, all crashing apps are complicated, with many threads. So I’m ignoring threads that are in epoll_wait, _poll, _futex_*, or other obvious waiting
Otherwise, chromium gave me the following stack traces (added demangling in post)
Stack trace of thread 6005:
#0 0x00007f3d48dabac5 realpath@@GLIBC_2.3 (libc.so.6 + 0x41ac5)
#1 0x000055b88396371a base::MakeAbsoluteFilePath(base::FilePath const&) (chromium + 0x8b0271a)
#2 0x000055b885133bef ui::(anonymous namespace)::ReadCursorFromTheme(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&) (chromium + 0xa2d2bef)
... (many more copies of the same function)
Stack trace of thread 6007:
#0 0x00007f3d48e6c45b readlink (libc.so.6 + 0x10245b)
#1 0x00007f3d48dabdfa realpath@@GLIBC_2.3 (libc.so.6 + 0x41dfa)
#2 0x000055b88396371a base::MakeAbsoluteFilePath(base::FilePath const&) (chromium + 0x8b0271a)
#3 0x000055b885133bef ui::(anonymous namespace)::ReadCursorFromTheme(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&) (chromium + 0xa2d2bef)
... (many more copies of the same function)
Stack trace of thread 6006:
#0 0x00007f3d48e6c45b readlink (libc.so.6 + 0x10245b)
#1 0x00007f3d48dabdfa realpath@@GLIBC_2.3 (libc.so.6 + 0x41dfa)
#2 0x000055b88396371a base::MakeAbsoluteFilePath(base::FilePath const&) (chromium + 0x8b0271a)
#3 0x000055b885133bef ui::(anonymous namespace)::ReadCursorFromTheme(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&) (chromium + 0xa2d2bef)
... (many more copies of the same function)
Stack trace of thread 4018:
#0 0x000055b883880af3 base::FilePath::DirName() const (chromium + 0x8a1faf3)
#1 0x000055b88388074f base::FilePath::GetComponents() const (chromium + 0x8a1f74f)
#2 0x000055b885133b58 ui::(anonymous namespace)::ReadCursorFromTheme(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&) (chromium + 0xa2d2b58)
... (many more copies of the same function)
Stack trace of thread 6022:
#0 0x000055b8839c0840 allocator_shim::internal::PartitionMalloc(unsigned long, void*) [clone .cfi] (chromium + 0x8b5f840)
#1 0x000055b88318f8cc base::allocator::dispatcher::internal::DispatcherImpl<base::PoissonAllocationSampler>::AllocFn(unsigned long, void*) [clone .cfi] (chromium + 0x832e8cc)
#2 0x000055b8839bfb9e operator new(unsigned long) (chromium + 0x8b5eb9e)
#3 0x000055b8831bb248 std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> >::basic_string(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, unsigned long, unsigned long, std::__Cr::allocator<char> const&) (chromium + 0x835a248)
#4 0x000055b883880b47 base::FilePath::DirName() const (chromium + 0x8a1fb47)
#5 0x000055b88388074f base::FilePath::GetComponents() const (chromium + 0x8a1f74f)
#6 0x000055b885133b58 ui::(anonymous namespace)::ReadCursorFromTheme(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&) (chromium + 0xa2d2b58)
... (many more copies of the same function)
Stack trace of thread 6016:
#0 0x00007f3d48e6c3dc read (libc.so.6 + 0x1023dc)
#1 0x000055b8836f92fe (anonymous namespace)::ShutdownDetector::ThreadMain() (chromium + 0x88982fe)
#2 0x000055b88394de07 base::(anonymous namespace)::ThreadFunc(void*) [clone .a67435033112019129ad5c28ddc47327] [clone .cfi] (chromium + 0x8aece07)
#3 0x00007f3d48dfaa42 start_thread (libc.so.6 + 0x90a42)
#4 0x00007f3d48e7a05c __clone3 (libc.so.6 + 0x11005c)
For Discord, it was these not currently polling/futex/suspended:
Stack trace of thread 7291:
#0 0x00007f409362eba5 realpath@@GLIBC_2.3 (libc.so.6 + 0x41ba5)
#1 0x000055fb77554528 n/a (.Discord-wrapped + 0x60bc528)
#2 0x000055fb786784ac n/a (.Discord-wrapped + 0x71e04ac)
#3 0x000055fb7867821b n/a (.Discord-wrapped + 0x71e021b)
... (many more copies of the same function)
Stack trace of thread 7290:
#0 0x00007f40936ef45b readlink (libc.so.6 + 0x10245b)
#1 0x00007f409362edfa realpath@@GLIBC_2.3 (libc.so.6 + 0x41dfa)
#2 0x000055fb77554528 n/a (.Discord-wrapped + 0x60bc528)
#3 0x000055fb786784ac n/a (.Discord-wrapped + 0x71e04ac)
#4 0x000055fb7867821b n/a (.Discord-wrapped + 0x71e021b)
... (many more copies of the same function)
Stack trace of thread 7313:
#0 0x00007f40936ef3dc read (libc.so.6 + 0x1023dc)
#1 0x000055fb73ad7633 n/a (.Discord-wrapped + 0x263f633)
#2 0x000055fb77543251 n/a (.Discord-wrapped + 0x60ab251)
#3 0x00007f409367da42 start_thread (libc.so.6 + 0x90a42)
#4 0x00007f40936fd05c __clone3 (libc.so.6 + 0x11005c)
Stack trace of thread 7702:
#0 0x00007f40936ef3dc read (libc.so.6 + 0x1023dc)
#1 0x00007f4093674753 _IO_file_underflow@@GLIBC_2.2.5 (libc.so.6 + 0x87753)
#2 0x00007f4093669000 __getdelim (libc.so.6 + 0x7c000)
#3 0x00007f3ff0f547ca get_reply (libspeechd.so.2 + 0x47ca)
#4 0x00007f3ff0f54bf0 spd_events_handler (libspeechd.so.2 + 0x4bf0)
#5 0x00007f409367da42 start_thread (libc.so.6 + 0x90a42)
#6 0x00007f40936fd05c __clone3 (libc.so.6 + 0x11005c)
and Spotify gave me similar results.
Doing coredumpctl debug -1 on the Discord crash and then a bt in gdb only shows me the realpath@@GLIBC_2.3 ()
thread, so I would guess that’s the origin of the segfault? Or just the first thread and that is coincidence?