btop
btop copied to clipboard
[BUG] Crashes when some cores are offline
Read the README.md and search for similar issues before posting a bug report!
Any bug that can be solved by just reading the prerequisites section of the README will likely be ignored.
Describe the bug
I've put some cores offline on my laptop to save power. btop crashes when online cores are not continuous. For example, when only core 2 and core 3 are offline among 8 cores (numbered from 0 to 7), btop crashes. But it works fine as long as some cores till the last one, like core 2 to core 7, are offline.
To Reproduce
Put some "middle" cores offline, then start btop.
echo 1 | sudo tee /sys/devices/system/cpu/cpu{0..7}/online # put every core online
echo 0 | sudo tee /sys/devices/system/cpu/cpu{2,3}/online # disable core 2 and 3
btop
Expected behavior
Show offline cores (like what htop
does), or renumber the cores by order, or simply skip them.
Screenshots
btop crashes when starting
htop shows offline cores
Info (please complete the following information):
- btop++ version: 1.2.8
- Binary:
- I first found the issue on the package from AUR
- (If compiled) Compiler and version:
- Since the the above version isn't compiled with debug flag, I got the source code of the same version from GitHub release and compiled it using g++ 12.2.0 with
make OPTFLAGS="-O0 -g"
, and it also crashed.
- Since the the above version isn't compiled with debug flag, I got the source code of the same version from GitHub release and compiled it using g++ 12.2.0 with
- Architecture: x86_64
- Platform: Linux
- (Linux) Kernel: 5.19.4-arch1-1
- Terminal used: alacritty 0.10.1
- Font used: Iosevka Fixed SS17
Additional context
contents of ~/.config/btop/btop.log
2022/08/28 (13:19:52) | ===> btop++ v.1.2.8
2022/08/28 (13:19:52) | DEBUG: Starting in DEBUG mode!
2022/08/28 (13:19:52) | INFO: Logger set to DEBUG
2022/08/28 (13:19:52) | DEBUG: Using locale en_US.UTF-8
2022/08/28 (13:19:52) | INFO: Running on /dev/pts/2
GDB Backtrace
If btop++ is crashing at start the following steps could be helpful:
Starting program: /home/user/Downloads/btop-1.2.8/bin/btop
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff75ff6c0 (LWP 18241)]
[New Thread 0x7ffff6dfe6c0 (LWP 18242)]
Thread 2 "btop" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff75ff6c0 (LWP 18241)]
0x00007ffff7aa14dc in ?? () from /usr/lib/libc.so.6
Thread 3 (Thread 0x7ffff6dfe6c0 (LWP 18242) "btop"):
#0 0x00007ffff7b208d6 in clone () from /usr/lib/libc.so.6
#1 0x00007ffff7a9f4c0 in ?? () from /usr/lib/libc.so.6
#2 0x00007ffff6dfe6c0 in ?? ()
#3 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7ffff75ff6c0 (LWP 18241) "btop"):
#0 0x00007ffff7aa14dc in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7a51998 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7a3b53d in abort () from /usr/lib/libc.so.6
#3 0x00007ffff7cd2112 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60
#4 0x00005555555fd2bc in std::deque<long long, std::allocator<long long> >::back (this=0x7ffff0004b50) at /usr/include/c++/12.2.0/bits/stl_deque.h:1484
#5 0x00005555555d0bbf in Cpu::draw[abi:cxx11](Cpu::cpu_info const&, bool, bool) (cpu=..., force_redraw=false, data_same=false) at src/btop_draw.cpp:635
#6 0x0000555555564d31 in Runner::_runner (_=0x0) at src/btop.cpp:459
#7 0x00007ffff7a9f78d in ?? () from /usr/lib/libc.so.6
#8 0x00007ffff7b208e4 in clone () from /usr/lib/libc.so.6
Thread 1 (Thread 0x7ffff7e98740 (LWP 18238) "btop"):
#0 0x00007ffff7b208d6 in clone () from /usr/lib/libc.so.6
#1 0x00007ffff7b21721 in ?? () from /usr/lib/libc.so.6
#2 0x00007ffff7a9f3c0 in ?? () from /usr/lib/libc.so.6
#3 0x00007ffff7a9fe8f in pthread_create () from /usr/lib/libc.so.6
#4 0x00007ffff7cd63da in __gthread_create (__args=<optimized out>, __func=0x7ffff7cd62e0 <std::execute_native_thread_routine(void*)>, __threadid=<optimized out>) at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:663
#5 std::thread::_M_start_thread (this=<optimized out>, state=std::unique_ptr<std::thread::_State> = {...}) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/thread.cc:147
#6 0x000055555561b940 in std::thread::thread<void (&)(Input::InputThr*), Input::InputThr*, void> (this=0x5555557850e8, __f=@0x55555561aee2: {void (Input::InputThr *)} 0x55555561aee2 <Input::InputThr::run(Input::InputThr*)>) at /usr/include/c++/12.2.0/bits/std_thread.h:142
#7 0x000055555561aebc in Input::InputThr::InputThr (this=0x5555557850a0) at src/btop_input.cpp:85
#8 0x000055555561b0f5 in Input::InputThr::instance () at src/btop_input.cpp:125
#9 0x0000555555611de0 in Input::poll (timeout=1000) at src/btop_input.cpp:144
#10 0x000055555556ab3a in main (argc=1, argv=0x7fffffffe188) at src/btop.cpp:939
Some UI were drawn when running with gdb.
@akamayu-ouo Do you mind trying with latest commits, have added code that should fix this. Will not display "offline" but will show a zero value for the core.
Seems they are missing from /proc/stat
when offline, and that was messing up the ordering.
Binaries at https://github.com/aristocratos/btop/actions/runs/3168752243
@aristocratos I've tried the binary. With core 2 and 3 (among total 8 cores) offline, btop hit the following error then exited.
ERROR: Exception in Shared::init() -> collect() : Mismatch betweeen /proc/stat core count and previously detected core count
With the last two cores (core 6 and 7) offline, btop didn't crash, but those cores were not shown either.
I suspect the cause is that sysconf(_SC_NPROCESSORS_ONLN)
gives the counts of available cores instead of the largest id number of the cores.
Maybe use _SC_NPROCESSORS_CONF
instead?
@akamayu-ouo
I was under the impression that _SC_NPROCESSORS_CONF
wouldn't include hyperthread cores, but seems like it does.
Try with latest commit. Binaries: https://github.com/aristocratos/btop/actions/runs/3172134964