aristocratos / btop Goto Github PK

Describe the solution you'd like
include a night-owl.theme file in the default options

Describe alternatives you've considered
i've already implemented it for myself and wanted to share it

Additional context
this theme is inspired by the original VS Code version by sdras

Please take a look at my screenshot.

I am using the latest x64 binary for linux

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
There are many benefits from using Cmake. Check out the documentation. Biggest one is portability. On platforms where Make isn't available, Cmake can still be made use of.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I'd like to see this project built with llvm, which requires Cmake support. Compiler optimizations are much better using llvm.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.
Additional context
Add any other context or screenshots about the feature request here.

Amazing work, very nice system monitor!
I would love to see btop being distributed as a package on the Arch User Repository (AUR). Writing the PKGBUILD should be quite straight forward. The setuid step of the installation could be a question to ask during that install.
I might even go ahead and submit a PR for this if I find some time to check out how the best practices for C++ apps are.

gdb, ps and htop can display custom thread names, the 16 char name of the thread explicitly written in by a developer. it would be useful to have either a column with this, or the option to add the column.

In the current version of README.md, 2 images have centered text: options-menu.png & help-menu.png

Centered text may look prettier, but is harder to read and scan down than left-aligned text. =)

Under 170 words more: https://practicaltypography.com/centered-text.html

(And remember right-aligned in case of i18n for RTL-languages)

Describe the bug

After install, the terminal keeps the text setting of white/bold

To Reproduce

I downloaded the linux x86-64 tbz file -

mkdir btop
wget https://github.com/aristocratos/btop/releases/download/v1.0.4/btop-1.0.4-linux-x86-64.tbz
PREFIX=test make install

My term is still bold white.

Expected behavior

I expect my term to reset.

I looked in the makefile and it's missing a \033[0m on the last printf statement in the install.

Screenshots

First run is before makefile modification, second is after.

Describe the bug

The installer script installs btop++ to /usr/local/bin/btop. On Centos this does not appear to be in path for 7 and 8. When I symlink it to /usr/local/sbin/btop it is found and executed.

Expected behavior

as btop runs with super user requirements will it not make sense to install it to /usr/local/sbin/ instead?

Describe the bug
For some reason btop randomly hangs (after a couple of mins or hours), CPU jumps to 100% for btop process.

To Reproduce
Not sure since it's random. Installed from snap edge though.

Expected behavior

Screenshots

[If applicable, add screenshots to help explain your problem.]

Info (please complete the following information):

• btop++ version: bpytop -v: 1.0.9
• Architecture: [x86_64, aarch64, etc.] uname -m
• Platform: [Linux, FreeBSD, OsX]: Ubuntu 21.04
• (Linux) Kernel: uname -r: 5.11.0.0-36-generic
• Terminal used: byobu
• Font used: default byobu fonts

Additional context

contents of ~/.config/btop/btop.log: doesn't exist, only btop.conf

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

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Provide a better TUI experience than what ncurses provides along with allowing Windows support eventually.
https://github.com/dankamongmen/notcurses
Describe the solution you'd like
A clear and concise description of what you want to happen.
I want to see better performance and graphics that notcurses provides that ncurses does not.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.
Additional context
Add any other context or screenshots about the feature request here.
It's a cross-platform Apache2 licensed library that's available in many Linux distribution package managers as well as Brew/Macports. It also provides C++ wrappers so that you don't need to use C code (which would be sub-optimal in a C++ project) with extensive documentation and discussion threads to help answer any questions you may have on how to use it.

Hi, I think that the program needs just one more FINAL rewrite but this time in the powerful HolyC Rust. It would be the final solution to all of our problems. Could you explain why did you rewrote the entire thing for the 2nd time?
PS. Don't take it too seriously. I just couldn't stop laughing on that announcement and couldn't stop myself from writing it. I really appreciate your hard work. Just the situation is a great meme. :D

When the number of CPU cores/threads is high (>99), there are two graphical issues:

• cores above 99 are shown as 10, 11 instead of 100, 110, etc.
• when the terminal window is not full screen (e.g., when is resized to occupy only half of the screen), the CPU usage graph overlap with the list of processes.

Screenshots

EDIT: The same happen with CPU and NET graphs

Which character(s) are used for the blank space in the CPU, network and memory graphs?

At the moment I'm using the font Cozette and btop looks like this:

My guess is one of the “Geometric Shapes”, which are not all supported by Cozette.

Before opening an issue at https://github.com/slavfox/Cozette, I wanted to confirm this suspicion.

Describe the bug

There is some text from the Load Average that spans to the next line.

To Reproduce

This happens to me all the time.

Expected behavior

Load AVG Should not span across multiple lines.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Add safer math than <cmath>. https://github.com/chromium/chromium/tree/master/base/numerics
Your response in the C++ suggestion discussion thread in bpytop:

dynamic_bitset and libpopcnt looks interesting though, I'm currently trying to optimize out some unnecessary string parsing in loops using std::bitset.

Also lastly, add https://github.com/microsoft/mimalloc to your build steps to improve allocation performance significantly. This will require #28 as it's extremely easy to add to Cmake file.

Describe the solution you'd like
A clear and concise description of what you want to happen.
Improved safety of the C++ code, better performance and other optimizations.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.

Additional context
Add any other context or screenshots about the feature request here.

It is often useful when monitoring the system to see if affinities are set as expected. the PROCESSOR column in htop, corresponding to the last processor that a process/thread was scheduled on would be a great addition as an optional column

Describe the bug

Building failing on Alpine linux 3.14.2 x86_64

To Reproduce

• curl -L https://github.com/aristocratos/btop/archive/refs/tags/v1.0.2.tar.gz| tar xzvf -
• cd btop-1.0.2/
• make

Linux alpine 4.9.65-1-hardened #2-Alpine SMP Mon Nov 27 15:36:10 GMT 2017 x86_64 GNU/Linux
alpine:~$ more /etc/alpine-release 
3.14.2
alpine:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-musl/10.3.1/lto-wrapper
Target: x86_64-alpine-linux-musl
Configured with: /home/buildozer/aports/main/gcc/src/gcc-10.3.1_git20210424/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-alpine-linux-musl --host=x86_64-alpine-linux-musl --target=x86_64-alpine-linux-musl --with-pkgversion='Alpine 10.3.1_git20210424' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-default-ssp --enable-cloog-backend --enable-languages=c,c++,d,objc,go,fortran,ada --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib --with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210424 (Alpine 10.3.1_git20210424) 
alpine:~$ 

Expected behavior

building without errors

Screenshots

alpine:~/btop-1.0.2$ make
 
 ██████╗ ████████╗ ██████╗ ██████╗
 ██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗   ██╗    ██╗
 ██████╔╝   ██║   ██║   ██║██████╔╝ ██████╗██████╗
 ██╔══██╗   ██║   ██║   ██║██╔═══╝  ╚═██╔═╝╚═██╔═╝
 ██████╔╝   ██║   ╚██████╔╝██║        ╚═╝    ╚═╝
 ╚═════╝    ╚═╝    ╚═════╝ ╚═╝      Makefile v1.2
PLATFORM   ?| Linux
ARCH       ?| x86_64
CXX        ?| g++ (10.3.1)
THREADS    :| auto
REQFLAGS   !| -std=c++20
WARNFLAGS  :| -Wall -Wextra -pedantic
OPTFLAGS   :| -O2 -ftree-loop-vectorize -flto=auto
LDCXXFLAGS :| -pthread -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector -fstack-clash-protection -fcf-protection
CXXFLAGS   +| $(REQFLAGS) $(LDCXXFLAGS) $(OPTFLAGS) $(WARNFLAGS)
LDFLAGS    +| $(LDCXXFLAGS) $(OPTFLAGS) $(WARNFLAGS)

Building btop++ (v1.0.2)
<...>
Linking and optimizing binary...
/usr/include/c++/10.3.1/ext/string_conversions.h: In function '__to_xstring.constprop':
/usr/include/fortify/stdio.h:70:28: error: inlining failed in call to 'always_inline' 'vsnprintf': function body can be overwritten at link time
   70 | _FORTIFY_FN(vsnprintf) int vsnprintf(char *__s, size_t __n, const char *__f,
      |                            ^
/usr/include/c++/10.3.1/ext/string_conversions.h:111:32: note: called from here
  111 |       const int __len = __convf(__s, __n, __fmt, __args);
      |                                ^
make[1]: *** [/tmp/ccLbJlLP.mk:56: /tmp/btop.OglgLe.ltrans18.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:167: btop] Error 1

Describe the bug

When I choose to only display CPU temperatures in pane 1, they end up being pushed to the right and only the first digit is visible.

To Reproduce

Only show the CPU pane (no 1)

Expected behavior

CPU temps should remain visible.

Screenshots

After a few seconds:

Info (please complete the following information):

• btop++ version: 1.0.1 and 1.0.2
• Binary: static binary from release
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 4.9.0-9-amd64
• (OSX/FreeBSD) Os release version: Debian 9 (Stretch)
• Terminal used: QTerminal
• Font used: Hack Nerd Font

PS: It's doesn't do it on xterm but xterm doesn't show the dots.

Describe the bug

ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068066) >= _Nm (which is 101)

To Reproduce

Run btop and wait

Expected behavior

Handling an exception with code

Screenshots

Info (please complete the following information):

• btop++ version: btop version: 1.0.1
• Architecture: [x86_64, aarch64, etc.] x86_64
• Platform: Linux
• (Linux) Kernel: 5.14.1
• (OSX/FreeBSD) Os release version:
• Terminal used: Konsole
• Font used: terminus

Additional context

contents of ~/.config/btop/error.log: empty

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

2021/09/20 (11:20:41) | ===> btop++ v.1.0.1
2021/09/20 (11:20:41) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068063) >= _Nm (which is 101)

2021/09/20 (11:39:42) | ===> btop++ v.1.0.1
2021/09/20 (11:39:42) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068063) >= _Nm (which is 101)

2021/09/20 (12:29:13) | ===> btop++ v.1.0.1
2021/09/20 (12:29:13) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068066) >= _Nm (which is 101)

2021/09/20 (15:19:59) | ===> btop++ v.1.0.1
2021/09/20 (15:19:59) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068066) >= _Nm (which is 101)

2021/09/20 (15:32:25) | ===> btop++ v.1.0.1
2021/09/20 (15:32:25) | DEBUG: Starting in DEBUG mode!
2021/09/20 (15:32:25) | INFO: Logger set to DEBUG
2021/09/20 (15:32:25) | DEBUG: Setting LC_ALL=ru_RU.utf8
2021/09/20 (15:32:25) | INFO: Running on /dev/pts/4
2021/09/20 (17:36:35) | ERROR: Exception in runner thread -> Proc:: -> array::at: __n (which is 18446744071562068068) >= _Nm (which is 101)
2021/09/20 (17:36:35) | INFO: Quitting! Runtime: 02:04:10

Describe the bug
Tried to run on pop OS 21.04. Crashes on startup with the following log:

/usr/include/c++/11/ranges:540: constexpr std::ranges::iota_view<_Winc, _Bound>::iota_view(std::type_identity_t<_Winc>, st
  3 d::type_identity_t<_Bound>) [with _Winc = int; _Bound = int; std::type_identity_t<_Winc> = int; std::type_identity_t<_Boun
  2 d> = int]: Assertion 'bool(__value <= __bound)' failed.                                                                   
  1 fish: “btop” terminated by signal SIGABRT (Abort)

It seems that it doesn't like the kitty terminal, but sometimes it seemed random. Unfortunately I wasn't taking note of everything before but I think it happens on kitty but not eg. on gnome terminal.

To Reproduce
Run the executable on the kitty terminal.

Info (please complete the following information):

• btop++ version: 1.0.2
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 5.11.0-7620-generic
• Terminal used: kitty
• Font used: Victor Mono

Additional context

contents of ~/.config/btop/btop.log

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

2021/09/20 (19:15:41) | ===> btop++ v.1.0.2
2021/09/20 (19:15:41) | DEBUG: Starting in DEBUG mode!
2021/09/20 (19:15:41) | INFO: Logger set to DEBUG
2021/09/20 (19:15:41) | DEBUG: Setting LC_ALL=en_US.UTF-8
2021/09/20 (19:15:41) | INFO: Running on /dev/pts/1

Ubuntu 18.04 after running btop command it immediately quits with message:
ERROR: Exception in runner thread -> Net:: -> stoul

I've tried to set net_iface to wlo1 but no luck, I can confirm files like /sys/class/net/wlo1/statistics/tx_bytes and /sys/class/net/wlo1/statistics/rx_bytes are present

Info (please complete the following information):

• btop++ version: 1.0.11
• Binary: static
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 5.4.0-84-generic

Additional context

contents of ~/.config/btop/btop.log

2021/09/30 (19:58:49) | ===> btop++ v.1.0.11
2021/09/30 (19:58:49) | DEBUG: Starting in DEBUG mode!
2021/09/30 (19:58:49) | INFO: Logger set to DEBUG
2021/09/30 (19:58:49) | DEBUG: Setting LC_ALL=en_US.UTF-8
2021/09/30 (19:58:49) | INFO: Running on /dev/pts/2
2021/09/30 (19:58:49) | ERROR: Exception in runner thread -> Net:: -> stoul
2021/09/30 (19:58:49) | INFO: Quitting! Runtime: 00:00:00

GDB Backtrace

If btop++ is crashing at start the following steps could be helpful:

1. run gdb btop

2. r to run, wait for crash and press enter

3. bt to get backtrace

4. Copy and paste the backtrace here:

Starting program: /usr/local/bin/btop 
ERROR: Exception in runner thread -> Net:: -> stoul
[Inferior 1 (process 26102) exited with code 01]
(gdb) bt
No stack.

I often use Linux in a Hyper-V VM for development which has dynamic memory allocation enabled. btop never changes the total memory after it is launched. That means when Hyper-V allocates more or less memory to the VM all memory stats become incorrect. I have to use htop instead since it updates the total memory while running. Othewise I love it.

Describe the bug

The documentation (README.md) and --help output both reference an option --utf-foce ("force start even if no UTF-8 locale was detected").

But this option doesn't exist. The actual option is --utf-force.

To Reproduce

Run btop --utf-foce and notice you get

kde@midna ~/tmp/btop $ btop --utf-foce
 Unknown argument: --utf-foce
 Use -h or --help for help.

Expected behavior

I expected btop to start up without issue (as it did when using --utf-force). I didn't not test on a non-UTF-8 locale yet but I would expect the option to work even in that case.

Info (please complete the following information):

• btop++ version: btop version: 1.0.0 (PS recommend adjusting the template here to read btop -v not bpytop -v)
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 5.14.0
• Terminal used: Konsole 21.11.70
• Font used: JetBrains Mono

Additional context

Let me know if you actually need this

Describe the bug

When a process uses over 999% with proc per core = true (more than 10 cores), btop prints the usage on 3 digits and truncate last numbers.

To Reproduce

1. Have a CPU with over 10 cores
2. install sysbench
3. sysbench cpu --threads=nproc run
4. watch btop which doesn't scale the cpu usage over 3 digits

Expected behavior

btop prints cpu usage on more than 3 digits (e.g. 1400%)

Screenshots

Info (please complete the following information):

• btop++ version: 1.0.9
• Binary: static binary from release
• (If compiled) Compiler and version:
• Architecture: [x86_64, aarch64, etc.] x86_64
• Platform: Linux (WSL2)
• (Linux) Kernel: 5.4.72-microsoft-standard-WSL2
• (OSX/FreeBSD) Os release version:
• Terminal used: Windows terminal + tmux
• Font used: MeslolGS NF

My 4 TB RAID-0 array doesn't show up. Also, my 4 TB RAID-1 array shows up as 2.41 GiB.

Info (please complete the following information):

• btop++ version: 1.0.6
• Binary: static binary btop-1.0.6-linux-i686.tbz
• (Linux) Kernel: 5.4.0-84-generic
• Terminal used: bash
• Font used: Default Linux Mint terminal font: Ubuntu Mono Regular

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Add support for Sixel, Kitty, and Iterm2's graphic protocols. Take a look at https://github.com/hackerb9/lsix for example (which just does Sixel).
Describe the solution you'd like
A clear and concise description of what you want to happen.
Add support for the graphic protocols in order to improve graphics further, and in some cases potentially boost performance as well. On Linux, start with detecting Kitty support. Kitty and Wezterm both support the Kitty protocol and notcurses favors this support when available, otherwise detect Sixel. Otherwise ignore altogether. On Mac, look for Iterm2 graphics protocol support (assuming you're not running on the aforementioned terminals), if it's not there, then search for Sixel and if that's not available, ignore there too.

Notcurses also has a fall-back layer where graphics protocols aren't supported, it will display things as best it can, which is still pretty well, if not quite as good which can make notcurses an optional dependency of this feature request (you may need to do very little as notcurses does detection for all 3 protocols).
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Do nothing.
Additional context
Add any other context or screenshots about the feature request here.

I compile btop from the source code last night
coredump when I run btop
here is my gdb info:

my env:

next I download the release binary btop which update 9 hours ago,it works,hope that bug is fix

Describe the bug

[A clear and concise description of what the bug is.]

To Reproduce

[Steps to reproduce the behavior:]

Expected behavior

[A clear and concise description of what you expected to happen.]

Screenshots

Just missing the 5 at the end: Pentium Silver J5005

Info (please complete the following information):

• btop++ version: btop -v 1.0.13
• Binary: [self compiled or static binary from release] self compiled

Is your feature request related to a problem? Please describe.
Keeping track of drive temps in my storage array is useful for tuning fan configuration, and this would be particularly in newer builds as ambient temps tend to change throughout the year. As my array sits a rack beside my desk keeping it both cool and quiet is important to me. Having temps available at a glance would be very useful in determining if x hotswap bay really needs a fan or not, or if y fan could be run at lower rpm. Additionally, Kernel 5.5+ is expected expose nvme drive temperatures to hwmon, and that should be extremely useful for keeping watch of their thermals in newer builds. Additionally drives running too hot or too cold can lead to more earlier than expected failure. The ability to keep track of their temps through btop would be of notable utility in this regard.

Describe the solution you'd like
Add hard drive temperatures to data collected and displayed.
I think current temperature alone would be sufficient for my uses- optionally a small graph would be great too.

I suggest the use of hwmon as it doesn't require additional packages. Furthermore, as you've already used hwmon as a collector method for CPU Temp in btop_collect.cpp - using a similar method to get temp1_input for each drive using hwmon's drivetemp module shouldn't be too much of a stretch.

Describe alternatives you've considered
hddtemp and smartctrl are both common solutions to retrieving this data but are are both dependent on installing additional packages. You could well check for them much as you did with various options like coretemp for the cpu temperature.

Additional context
With hwmon's drivetemp module loaded (which it may or may not be by default- sudo modprobe drivetemp should load it on supporting kernel versions if it isn't already) you can grab current temperature in Milli-degrees Celsius from /sys/class/hwmon/hwmon*/temp1_input obviously the value returned would need to be multiplied accordingly (value*0.001) before being displayed.

with the drivetemp module loaded:

• hwmon drivetemp module will return "drivetemp" in /sys/class/hwmon/hwmon*/name which will be useful in separating drivetemp collection from cpu temp collection.
• current temperature values for each drive are stored in /sys/class/hwmon/hwmon*/temp1_input
  temp1_input should always be available while the drivetemp module is loaded, additional information such as temp1_min, temp1_max, temp1_lowest, temp1_highest, and temp1_crit values may or may not be set by the drive.
• you can get the mount (eg: sda,sdb,sdc,etc.) from /sys/class/hwmon/hwmon*/device/block/ for association purposes with info already retrieved from proc and fstab in btop_collect.cpp for displaying under proper drive label
• you can also notably get the drive model from /sys/class/hwmon/hwmon*/device/model

Describe the bug

Running on RHEL 7.7 at work, using the statically compiled binary 1.0.9, it complains of no UTF-8 locale detected. While locale is:
[jdehaes@berx771 Snape]$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

When using the --utf-force flag, btop works perfectly. We have the same on other RHEL 7.x boxes.
I can not compile/debug btop on this machine (as its compilers are too old - even with gcc 8.3 -std=c++20 is not available). On a RHEL 8 system this just works. I can compile/debug there (after installing gcc 10 toolchain), but useless as the problem doesn't occur there. The locale settings are identical on that system.

To Reproduce

Get a RHEL 7.7 (probably any 7.x will do) system (via docker?) and copy the btop binary. It will complain although locale is UTF-8.

Expected behavior

btop can run with the --utf-force flag.

[jdehaes@berx771 Snape]$ btop
ERROR: No UTF-8 locale detected!
Use --utf-force argument to force start if you're sure your terminal can handle it.

[If applicable, add screenshots to help explain your problem.]

Info (please complete the following information):

• btop++ version: 1.0.9
• Binary: static binary from release
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 3.10.0-1062.4.1.el7.x86_64
• Terminal used: mate-terminal
• Font used: Noto Mono for Powerline Regular

Additional context

contents of ~/.config/btop/btop.log -> nothing there other than no UTF-8 locale detected.

Hi @aristocratos ,

Hope you are all well !

I was wondering if it would be possible to create an homebrew formula for your great project :-)

Ps. apt package also ^^

Cheers,
Luc Michalski

Describe the bug

When attempting to run on a Raspberry Pi 2, btop crashes immediately.

To Reproduce

1. Download btop for armhf, extract and install
2. Run it

Expected behavior

The program starts properly with no errors.

Screenshots

Terminal output:

pi@raspberrypi:~/btop $ sudo make install

 ██████╗ ████████╗ ██████╗ ██████╗
 ██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗   ██╗    ██╗
 ██████╔╝   ██║   ██║   ██║██████╔╝ ██████╗██████╗
 ██╔══██╗   ██║   ██║   ██║██╔═══╝  ╚═██╔═╝╚═██╔═╝
 ██████╔╝   ██║   ╚██████╔╝██║        ╚═╝    ╚═╝
 ╚═════╝    ╚═╝    ╚═════╝ ╚═╝      Installer

Installing binary to: /usr/local/bin/btop
Installing doc to: /usr/local/share/btop
Installing themes to: /usr/local/share/btop/themes
pi@raspberrypi:~/btop $ sudo make setuid
File: /usr/local/bin/btop
Setting owner root:root
Setting SUID bit
pi@raspberrypi:~/btop $ btop
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
Aborted

Info (please complete the following information):

• btop++ version: btop version: 1.0.2
• Architecture: armv7l
• Platform: Linux (Raspberry Pi OS 2021-05-07)
• Linux Kernel: 5.10.60-v7+
• Terminal used: PuTTY over SSH
• Font used: Source Code Pro Semibold

Additional context

Logs are very unhelpful:

2021/09/21 (01:24:34) | ===> btop++ v.1.0.2
2021/09/21 (01:24:34) | DEBUG: Starting in DEBUG mode!
2021/09/21 (01:24:34) | INFO: Logger set to DEBUG

[end of log file]

Describe the bug

displays incorrectly (see screenshots)

To Reproduce

1. install emacs 27
2. install vterm, the way I'm doing it is with doom

git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
~/.emacs.d/bin/doom install
# open ~/.doom.d/init.el, uncomment line with `vterm` by deleting leading semicolons
~/.emacs.d/bin/doom sync

3. open emacs
4. run vterm - either with Meta-x shortcut and search for "+vterm/here", or, press [Space o t]
5. run btop

Expected behavior

render similarly to bpytop

Screenshots

btop

bpytop

Info (please complete the following information):

• btop++ version: 1.0.12
• Binary: https://archlinux.org/packages/community/x86_64/btop/
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 5.12.15-arch1-1
• (OSX/FreeBSD) Os release version: not sure
• Terminal used: https://github.com/akermu/emacs-libvterm
• Font used: JetBrains Mono

Additional context

❯ cat ~/.config/btop/btop.log 

2021/10/02 (12:42:00) | ===> btop++ v.1.0.12
2021/10/02 (12:42:00) | DEBUG: Starting in DEBUG mode!
2021/10/02 (12:42:00) | INFO: Logger set to DEBUG
2021/10/02 (12:42:00) | DEBUG: Using locale en_US.UTF-8
2021/10/02 (12:42:00) | INFO: Running on /dev/pts/1
2021/10/02 (12:42:00) | INFO: Forcing tty mode: setting 16 color mode and using tty friendly graph symbols
2021/10/02 (12:42:06) | INFO: Quitting! Runtime: 00:00:06

I also tried flipping all setting in general tab, but it didn't help

It would be useful to pick the orientation of the windows. the default works well for "landscape" windows, but not for "portrait" type windows. for instance, i might want procs and network stacked one on top of the other.
i guess the orientation options as they are are too restrictive: maybe let the user pick left/right/top/bottom for any panel.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I notice two issues:

1. When I update my btop to a new version, the version number in the first line ~/.config/btop/btop.conf file will change
2. when I exit btop with a different layout, some parts of the btop.conf will be different

The btop.conf file should only be modified when you manually modify it.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Put those parts that are easy to change into another file such as ~/.cache/btop/btop.conf, since I sync my btop.conf with git in dotfiles, every time the btop changes, it is annoying that I got a new modification in my dotfiles.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Hello,

Awesome update of htop so far, thanks for your work.
Only thing I've noted so far is that download and upload values are the same :

• btop++ version: 1.06
• Binary: complied with make STATIC=true
• (If compiled) Compiler and version: gcc-10 10.2.1
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 5.10.0-8-amd64
• (OSX/FreeBSD) Os release version:Debian 11

Logs :

2021/09/24 (09:40:25) | ===> btop++ v.1.0.6
2021/09/24 (09:40:25) | DEBUG: Starting in DEBUG mode!
2021/09/24 (09:40:25) | INFO: Logger set to DEBUG
2021/09/24 (09:40:25) | DEBUG: Setting LC_ALL=fr_FR.UTF-8
2021/09/24 (09:40:25) | INFO: Running on /dev/pts/0
2021/09/24 (09:40:32) | INFO: Quitting! Runtime: 00:00:07

Describe the bug

While compiling something my CPU spikes over 100% well into the 300% area in the proc tree

It might be interesting to note that it only occured when a single process was going ham at the cpu, if i compile clang++ over multiple processes i have no problem anymore

To Reproduce

Compile unreal engine from source

Expected behavior

CPU Should be maxed at 100% with all proc combined

Screenshots

Bug example

Working example

Info (please complete the following information):

• btop++ version: btop version: 1.0.4
• Binary: static binary from release
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 5.13.0-7614-generic
• (OSX/FreeBSD) Os release version: Pop!_OS 21.04
• Terminal used: Alacritty
• Font used: MesloLGS

2021/09/22 (09:29:34) | ===> btop++ v.1.0.4 2021/09/22 (09:29:34) | ERROR: Terminal size to small for current config. (WxH) Current: 94x22 | Needed: 80x24 Resize terminal or disable some boxes in config file to fix this.

Describe the solution you'd like
Any chance there's already a built in way to change the banner colors to the theme selected?
Or maybe just print it out as text instead of ASCII art. The banner doesn't match the theme that i'm using at all right now (nord), cheers

First of all: Nice work! I'm looking forward to using btop++ on my machines.

Describe the bug

When $LANG has a non-UTF-8 locale set (or a locale without the exact suffix UTF-8, e.g. ´de_DE.utf8`), the program terminates with a segfault.

To Reproduce

$ LANG=de_DE.utf8 ./bin/btop # for a build inside the repo

Expected behavior

The program should accept the locale and start as expected or don't accept the locale and exit with an error message.

Screenshots

No screenshots, but see this gdb output:

$ gdb --args ./bin/btop --debug                                                                                                                                       ✔  183
GNU gdb (Gentoo 10.2 vanilla) 10.2
Copyright (C) 2021 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 ./bin/btop...
(gdb) r
Starting program: /home/nex/build/btop/bin/btop --debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7c5b15e in __pthread_clockjoin_ex () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007ffff7c5b15e in __pthread_clockjoin_ex () from /lib64/libpthread.so.0
#1  0x0000555555561c74 in clean_quit (sig=-1) at src/btop.cpp:187
#2  0x0000555555561f40 in _exit_handler () at src/btop.cpp:232
#3  0x00007ffff7ad2f67 in ?? () from /lib64/libc.so.6
#4  0x00007ffff7ad310a in exit () from /lib64/libc.so.6
#5  0x00005555555673b2 in main (argc=2, argv=0x7fffffffd908) at src/btop.cpp:728
(gdb) q
A debugging session is active.

	Inferior 1 [process 47362] will be killed.

Quit anyway? (y or n) y

Info (please complete the following information):

• btop++ version: 1.0.0
• Architecture: x86_64
• Platform: Gentoo Linux
• (Linux) Kernel: 5.4.80-gentoo-x86_64
• Terminal used: x11-terms/terminator
• Font used: Anonymous Pro Regular

Additional context

contents of ~/.config/btop/error.log: file non-existent since the program couldn't start properly

Since I have LANG=de_DE.utf8 set and thus a UTF-8-capable locale, starting btop with --utf-force helped as a workaround. However, the proper behavior should be that LANG=de_DE.utf8 should be recognized as UTF-8-capable locale and thus the program shouldn't even get to the point of trying to generate an error message.

I've already found the offending line:

with a bit of context:

So one issue is that the locale didn't get recognized as UTF-8 properly.
The more important issue here is that btop probably tries to join a pthread which it never created–more or less a use-before-malloc:

So the proper fix for the second issue is probably just checking if Runner::runner_id is a valid thread (i.e. has been created).
But on that notice, why bother using pthread directly and not std::thread?
If it's because an std::thread on the stack automatically starts a thread, just wrap it inside a std::unique_ptr.
A check using std::unique_ptr::operator bool then is a very convenient method to check if there is a thread possibly running.
Also, you don't have to take care of cleaning up after the thread since std::unique_ptr does that for you.
But that's just an idea.
I suppose you had a valid reason to use pthread directly.

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
All statistics already present in btop, but filtered in a per-cgroup basis.

Describe alternatives you've considered
top and htop are tools that can show which cgroup container a process is running on, but that's about it.

Additional context
In a context where containers (Docker, LXC, podman, containerd, etc.) are commonly used, I believe having the ability to filter statistics for each container for debugging purposes is a 'must' feature to have.

For some reason, default btop display doesn't show properly cores temperature

Is it not possible to make the CPU box a bit bigger when there are only 2 or 4 cores? On AMD it looks a bit squashed.

Describe the solution you'd like
As there are only 2 cores on my VM the AMD CPU Model name is not displayed optimally.

Can the box not be sized on the core count ( > 4 ) , and if Temperature is being displayed, to dynamically size it? I see that the box is already sized on the height of the terminal window. Maybe make it configurable that if the temperature is not displayed to allow that space to be used for displaying the CPU core load using that space? Making the Core graph a bit wider and a bit taller.

Or scroll the text when you click the CPU model?

A lot of users across various Linux Distros would have convenient access to this application if it were distributed as Flatpak and/or Snap. It would also greatly help discoverability of this application if it was published there.

Have you considered publishing this as a Flatpak on Flathub and/or as a Snap on the Snap store? Flatpak is the more popular universal app format out of the two (because it's more open by design), so if you had to choose only one, I'd go with Flatpak.

Hello,

Thank you for this resource monitoring utility, but may I recommend that you consider package it as an AppImage for easy of use and wider adoption, please.

AppImages are very easy to create and can easily be automated for new releases.

In btop, processes run by LDAP users show up with their UIDs instead of usernames in the processes table. I am using OpenLDAP and SSSD for user management, configured according to the ArchWiki. This bug does not occur when using bpytop or htop.

To Reproduce

Run btop on a machine with processes that are being run by LDAP users.

Expected behavior

The LDAP users' usernames should show up in the processes table instead of their UIDs.

Screenshots

Info (please complete the following information):

• btop++ version: 1.0.10
• Binary: From Arch Linux community repository
• Architecture: [x86_64, aarch64, etc.]: x86_64
• Platform: Arch Linux
• (Linux) Kernel: 5.14.7-arch1-1
• Terminal used: Konsole
• Font used: Hack

I know you already added hjkl navigation to bpytop. Is it missing or am i just too stupid to find out how to configure?

As an idea you may be able to get away with less requests like these if users could add their keybindings to the config file. Not sure how much time would go into implementing that but just a suggestion.

Have to say that i really like this version. As much as i love python this kind of thing is better written in a lower level language.

Describe the bug

[A clear and concise description of what the bug is.]

To Reproduce

randomly scroll process list.

Expected behavior

[A clear and concise description of what you expected to happen.]

Screenshots

[If applicable, add screenshots to help explain your problem.]

Info (please complete the following information):

• btop++ version: master
• Binary: self compiled
• (If compiled) Compiler and version:gcc version 11.1.0 (GCC)
• Architecture: [x86_64, aarch64, etc.] x86_64
• Platform: Linux
• (Linux) Kernel: 5.14.0-0-MANJARO
• (OSX/FreeBSD) Os release version:
• Terminal used: iterm2/fish
• Font used:

Additional context

contents of ~/.config/btop/btop.log

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

GDB Backtrace

Thread 2 (LWP 2749 "btop"):
#0 0x00007f2bc7bd0a9d in syscall () from /usr/lib/libc.so.6
#1 0x0000563a794fda5e in void std::__detail::__platform_wait(int const*, int) ()
#2 0x0000563a795516c7 in Runner::_runner(void*) ()
#3 0x00007f2bc7cad299 in start_thread () from /usr/lib/libpthread.so.0
#4 0x00007f2bc7bd6053 in clone () from /usr/lib/libc.so.6
Thread 1 (LWP 2748 "btop"):
#0 0x00007f2bc7cb687c in read () from /usr/lib/libpthread.so.0
#1 0x00007f2bc7eed662 in std::__basic_file::xsgetn (this=this@entry=0x7f2bc8037b08 <__gnu_internal::buf_cin+104>, __s=0x563a7996ddd0 "\033[A0;122;33m\033[<0;114;34m\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M\033[<65;97;45M", __n=__n@entry=8191) at basic_file.cc:331
#2 0x00007f2bc7f2eb61 in std::basic_filebuf<char, std::char_traits >::underflow (this=0x7f2bc8037aa0 <__gnu_internal::buf_cin>) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:487
#3 0x00007f2bc7ec7ee1 in std::basic_streambuf<char, std::char_traits >::sgetc (this=0x7f2bc8037aa0 <__gnu_internal::buf_cin>) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:343
#4 std::basic_streambuf<char, std::char_traits >::sgetc (this=) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:343
#5 std::basic_streambuf<char, std::char_traits >::snextc (this=) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:308
#6 std::istream::ignoreXX (this=0x7f2bc80385a0 std::cin, __n=9223372036854775807) at /build/gcc/src/gcc/libstdc++-v3/src/c++98/compatibility.cc:96
#7 0x0000563a7951fa67 in Input::getabi:cxx11 ()
#8 0x0000563a794e2abd in main ()

Describe the bug

When I close a branch in the process tree view, the processes under that branch are moved to the bottom of the list.

To Reproduce

Close a branch and scroll down to the end of the list.

Expected behavior

The processes should disappear.

Screenshots

Info (please complete the following information):

• btop++ version: 1.0.5
• Binary: self compiled
• (If compiled) Compiler and version: 11.1.0, 10.2.0
• Architecture: x86_64, armv7l
• Platform: Linux
• (Linux) Kernel: 5.14.6-zen1-1-zen, 5.10.63-9-ARCH
• (OSX/FreeBSD) Os release version:
• Terminal used: urxvt, st, tty

Describe the bug
btop crashes quite a few times while attempting to launch it via sxhkd

2021/09/21 (08:49:04) | ===> btop++ v.1.0.2
2021/09/21 (08:49:04) | ERROR: Runner thread died unexpectedly!

It works just fine when I manually launch my terminal and type btop

My sxhkd config:

# btop++ process viewer
super + b
	alacritty -e btop

To Reproduce
Attempt to launch btop via sxhkd

Info (please complete the following information):

• btop++ version: 1.0.2
• Architecture: x86_64
• Platform: Arch Linux
• (Linux) Kernel: 5.14.6-arch1-1
• Terminal used: alacritty
• Font used: jetbrains nerd fonts mono

Dear community:

I have tried to install the latest version of btop inside of WSL 1.0 and encountered some issue. After the installation process has finished successfully, I tried to launch btop, but there is only an error message showing up:

-bash: /usr/local/bin/btop: cannot execute binary file: Exec format error

Did someone encounter this problem before, or know the solution for this problem?

regards:

Benedikt