The most recent changes i can remember doing between it working and not is that i disabled systemd-resolved to use dnsmassq.
Running Ubuntu 20.04
Linux ubpad 5.4.0-37-generic #41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
# htop
htop 2.2.0 aborting. Please report bug at http://hisham.hm/htop
Please include in your report the following backtrace:
[0x4146e3]
[0x454860]
/lib/x86_64-linux-gnu/libc.so.6(getauxval+0x1b)[0x7f13ce216fbb]
/lib/x86_64-linux-gnu/libnss_systemd.so.2(+0x10fee)[0x7f13cdf5dfee]
/lib/x86_64-linux-gnu/libnss_systemd.so.2(+0x11356)[0x7f13cdf5e356]
/lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwuid_r+0x12e)[0x7f13cdf75e2e]
[0x4aba05]
[0x4ab3d8]
[0x40cf2f]
[0x413659]
[0x414564]
[0x409b77]
[0x400c21]
[0x445889]
[0x40130a]
Additionally, in order to make the above backtrace useful,
please also run the following command to generate a disassembly of your binary:
objdump -d `which htop` > ~/htop.objdump
and then attach the file ~/htop.objdump to your bug report.
Thank you for helping to improve htop!
Aborted (core dumped)
@ravenmeister it looks like this may be related to the resolver change you mention - the initial failure around 0x4aba05 appears to be inside a function named __getpwuid_r, which I imagine is part of glibc.
Activity
natoscott commentedon Jul 13, 2020
@ravenmeister it looks like this may be related to the resolver change you mention - the initial failure around 0x4aba05 appears to be inside a function named __getpwuid_r, which I imagine is part of glibc.
It looks alot like the issue below actually, which was apparently resolved by glibc upgrade.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=40870