btop: [BUG] SIGSEGV ( if using libc++ )

Describe the bug

SIGSEGV boundary error .

happens at machine with glibc Compiled with clang , LTO-thin , O3, native flags, debug symbols. Used libc++ , compiler-rt . e.g. gentoo clang-profile.

To Reproduce

run btop for several hours.
everything fine, until a SIGSEGV happens.

Expected behavior

not sigsegv

Screenshots

here should be photo of btop with braile style under tmux with text somewhere SIGSEGV …

Info (please complete the following information):

btop++ version: btop -v : btop version: 1.2.13
Binary: “self compiled” gentoo
(If compiled) Compiler and version: clang 16.0.6 CXXFLAGS="… O3, -flto=thin , native flags for clang, pipe, stdlib=libc++ compiler-rt.
Architecture: x86_64
Platform: Linux Gentoo clang profile chrooted from gentoo LiveCD.
(Linux) Kernel: 6.1.31-gentoo-x86_64
Terminal used: kde plasma wayland -> kitty -> ssh to LiveCD kde plasma -> chroot to gentoo with clang profile -> tmux
Font used: idk, didn’t changed I guess. In kitty it’s set to JetBrainsMono Nerd Font

Additional context

contents of ~/.config/btop/btop.log: nothing related.

(try running btop with --debug flag if btop.log is empty)

GDB Backtrace

O3 + LTO-thin + debug symbols got me here: gdb btop … wait … bt :

#0  0x00007ffff7f3e92b in std::__1::basic_streambuf<char, std::__1::char_traits<char> >::uflow() ()
   from /usr/lib64/libc++.so.1
#1  0x00007ffff7f4118f in std::__1::basic_istream<char, std::__1::char_traits<char> >::ignore(long, int)
    () from /usr/lib64/libc++.so.1
#2  0x00005555556d53ac in Proc::collect (no_update=false) at src/linux/btop_collect.cpp:1866
#3  0x000055555558a5db in Runner::_runner () at src/btop.cpp:548
#4  0x00007ffff7d053ac in ?? () from /lib64/libc.so.6
#5  0x00007ffff7d8526c in ?? () from /lib64/libc.so.6

I’ll try glibc compile with debug symbols, wait a day-two for me to get the error again. Then I’ll try btop under O0 , LTO-thin and debug symbols.

About this issue

Original URL
State: open
Created 9 months ago
Comments: 37 (18 by maintainers)

Most upvoted comments

Alright, I found a setup to consistently reproduce:

Install stress-ng
launch btop, set reload interval to 100ms
Run stress-ng --fork 100 & ( sleep 0.07 && killall stress-ng )

Seems to be caused by processes very quickly opening and being terminated. UBSan also triggers on the segfault, here’s the output if it’s of use:

UndefinedBehaviorSanitizer:DEADLYSIGNAL
==5966==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7efe0fc9974b bp 0x7efe100750f0 sp 0x7efe10075070 T5967)
==5966==The signal is caused by a READ memory access.
==5966==Hint: address points to the zero page.
    #0 0x7efe0fc9974b in std::__1::basic_streambuf<char, std::__1::char_traits<char>>::uflow() (/lib/libc++.so.1+0x9c74b)
    #1 0x55793c8a46c7 in __sanitizer::ReportDeadlySignal(__sanitizer::SignalContext const&, unsigned int, void (*)(__sanitizer::SignalContext const&, void const*, __sanitizer::BufferedStackTrace*), void const*) (/usr/bin/btop+0x5c06c7)
    #2 0x55793c8a49e8 in __sanitizer::HandleDeadlySignal(void*, void*, unsigned int, void (*)(__sanitizer::SignalContext const&, void const*, __sanitizer::BufferedStackTrace*), void const*) (/usr/bin/btop+0x5c09e8)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/lib/libc++.so.1+0x9c74b) in std::__1::basic_streambuf<char, std::__1::char_traits<char>>::uflow()
==5966==ABORTING

vimproved on Sep 22, 2023

The musl binary is static, it works on all 2.6+ kernels.

ok, after testing nobounce’s ebuild and after nobounce’s ebuild with GCC .

Gerodote on Sep 18, 2023

As long as it’s the git version it’s fine

imwints on Sep 18, 2023