btop: [BUG] Btop hangs

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

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 47 (22 by maintainers)

Most upvoted comments

Thanks @aristocratos. After 2 weeks of uptime of 1.2.0 I think it’s safe to say it’s fully resolved.

@vaygr @tomterl @dfuehrer @mh166 It has now been stable for 24 hours, I believe this to be fixed finally in v1.0.16

@vaygr It’s possible there was two seperate issues causing stalls and the removal of the async threads fixed on of them. But there might still be the possibility of a stall from the ifstream issue in the build you are running. Both are fixed in latest commit that have been running stable in my test setup for over 7 hours now.

Will wait for at least 24 hours stable before pushing a new release with the current fixes. After that we can hopefully close this issue for good 😃

@dfuehrer @vaygr @tomterl I’ve removed the use of async threads in the secondary thread which I believe might have been the cause of the issue, and they weren’t really serving any use. Probably reduced cpu usage a bit by removing them.

So please make clean and build with latest commit or run the latest static build to see if it’s still stalling for you.

@vaygr I believe I might have fixed it in latest commit. Still stable in my test setup so far.

Static binaries in latest build

@mh166 @jmakov @vaygr Last one didn’t work I just noticed. But I’ve replaced the clock_nanosleep() trigger with cpu pause instructions in the loop causing the problem in the latest commits.

If you need static binaries you can get them from the continuous build workflow

Just a dumb suggestion: spdlog + rotating file logger e.g. max 10MB. Will try out installing from the repo as you suggest.

@jmakov For best result make distclean and make OPTFLAGS="-O0 -g" to get as much debugging info as possible with gdb. And then when stalled, try to get as much of the current stack as possible to find out exactly what’s going wrong.

I’m in no way an expert in the workings of gdb so can’t say for sure, but logging “live” gdb debugging output to a file would probably be a bit tricky (and quickly get large) with the amount of data it likely would generate.

It’s been stable for the last 2 days so that was the issue, thanks

@jmakov Fixed in release v1.0.11

@jmakov If this happens consistently for you would you mind trying the following:

  1. Start btop with gdb -ex run btop you will se some gdb output next to the clock, just ignore that.
  2. When btop hangs, press CTRL+C , if gdb prompts about more information just press enter.
  3. Press CTRL+L to clear the screen
  4. Type command bt to get the backtrace
  5. Post the backtrace here

That way we could maybe figure out were it gets stuck.