-
-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
segfault when compiling as static #503
Comments
Can you try to compile with debug symbols enabled? Doing so gives a better trace in the error message). Given from the function that's active in the trace this is likely somewhere in |
if by
nope, i don't know, not sure how to check, but in a static build, should it matter what the runtime glibc is? |
No. Was referring to providing
Some of the called functions in glibc are dependent on structures that are created by different processes and communicated to the local process. This is most noticeable with things like PAM, but |
btw have you (or anyone) tried to reproduce it? seems compiling it with
didn't make a difference, still got the same output,
|
./configure --enable-static --disable-unicode --disable-hwloc --disable-setuid --disable-sensors --disable-capabilities --disable-openvz --disable-vserver --disable-ancient-vserver --disable-delayacct --disable-linux-affinity
make -j $(nproc)
./htop works here on Ubuntu 20.04.1 LTS, also AMD64 aka cannot reproduce |
@fasterit thanks, can you upload the htop you produced? it'd be interesting to see if that same binary is crashing on my system or not |
Can reproduce on Debian sid with Starting program: /home/christian/Coding/workspaces/htop/htop > run.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7963350 in _nss_systemd_is_blocked () at ../src/nss-systemd/nss-systemd.c:639
639 ../src/nss-systemd/nss-systemd.c: No such file or directory.
(gdb) bt full
#0 0x00007ffff7963350 in _nss_systemd_is_blocked () at ../src/nss-systemd/nss-systemd.c:639
No locals.
#1 0x00007ffff7964507 in userdb_getpwuid (errnop=<synthetic pointer>, buflen=1024, buffer=0x5508b0 "", pwd=0x54c440 <resbuf>, uid=63378) at ../src/nss-systemd/userdb-glue.c:111
hr = 0x0
r = <optimized out>
hr = <optimized out>
r = <optimized out>
__PRETTY_FUNCTION__ = {<optimized out> <repeats 16 times>}
#2 _nss_systemd_getpwuid_r (uid=63378, pwd=0x54c440 <resbuf>, buffer=0x5508b0 "", buflen=1024, errnop=0x54e300) at ../src/nss-systemd/nss-systemd.c:169
status = <optimized out>
e = <optimized out>
_saved_errno_ = 0
_saved_sigset = {__val = {0, 4919111, 8320808640339734111, 8387223540451861876, 32193032215689072, 4919047, 140737347416736, 94489280512, 6729072, 5292379, 5555264, 15912848161058534912, 5563136, 140737488343600, 0, 63232}}
__PRETTY_FUNCTION__ = "_nss_systemd_getpwuid_r"
_found = <optimized out>
__assert_in_set = {<optimized out>, <optimized out>}
#3 0x00000000004aa713 in getpwuid_r ()
No symbol table info available.
#4 0x00000000004aa0c3 in getpwuid ()
No symbol table info available.
#5 0x0000000000415487 in UsersTable_getRef (this=0x550cc0, uid=63378) at UsersTable.c:35
userData = <optimized out>
name = <optimized out>
#6 0x000000000041ae6c in LinuxProcessList_recurseProcTree (this=0x550e50, parentFd=<optimized out>, dirname=<optimized out>, parent=0x0, period=279062.25, now=1612029284743) at linux/LinuxProcessList.c:1411
pid = <optimized out>
proc = <optimized out>
procFd = 4
command = "sleep\000lctl\000r\000events_unbound\000icient", '\000' <repeats 94 times>
lasttimes = 0
tty_nr = <optimized out>
lp = <optimized out>
percent_cpu = <optimized out>
name = <optimized out>
preExisting = false
pl = 0x550e50
entry = <optimized out>
settings = 0x555ea0
dirFd = 3
dir = <optimized out>
cpus = 4
hideKernelThreads = true
hideUserlandThreads = true
errorReadingProcess = <optimized out>
__PRETTY_FUNCTION__ = "LinuxProcessList_recurseProcTree"
#7 0x000000000041c563 in ProcessList_goThroughEntries (super=super@entry=0x550e50, pauseProcessUpdate=pauseProcessUpdate@entry=false) at linux/LinuxProcessList.c:1988
this = 0x550e50
settings = <optimized out>
period = 279062.25
tv = {tv_sec = 1612029284, tv_usec = 743522}
now = <optimized out>
rootFd = -100
#8 0x00000000004118af in ProcessList_scan (this=this@entry=0x550e50, pauseProcessUpdate=pauseProcessUpdate@entry=false) at ProcessList.c:572
now = {tv_sec = 5599984, tv_nsec = 5901632}
firstScanDone = true
#9 0x0000000000401edc in main (argc=<optimized out>, argv=<optimized out>) at htop.c:468
lc_ctype = <optimized out>
flags = {pidMatchList = 0x0, commFilter = 0x0, userId = <optimized out>, sortKey = 0, delay = -1, useColors = true, enableMouse = true, treeView = false, allowUnicode = <optimized out>, highlightChanges = <optimized out>, highlightDelaySecs = <optimized out>}
ut = 0x550cc0
pl = 0x550e50
settings = 0x555ea0
header = 0x5561c0
panel = 0x7fffffffda50
state = {settings = 0x555ea0, ut = 0x550cc0, pl = 0x550e50, panel = 0x5a0d40, header = 0x5561c0, pauseProcessUpdate = false, hideProcessSelection = false}
scr = 0x5572f0
(gdb) quit |
did it segfault in _nss_systemd_is_blocked() ? the only reference i could find to that function is https://github.com/systemd/systemd/blob/main/src/nss-systemd/nss-systemd.c with _nss_systemd_is_blocked() defined as
and _blocked defined as
uhm, may suggest that the pointer to the |
Hoping to provide some insight since I recently had to debug this issue for our containers running a statically linked binary that used nss-systemd. As I understand it, statically linked binaries do all of their thread local storage (TLS) allocations at the start of the program based on what was linked in. NSS modules are dlopen-ed so if they use TLS they do not get allocated in the statically linked binary scenario (hence the segfault when trying to access it). One way to fix this is to rebuild systemd. You can add Another way to get around this is to remove "systemd" from Of course you can also try to fix this upstream. The commit introducing the thread local to nss-systemd is in systemd/systemd@037b0a4 which was relatively recent (systemd 246, so 2 versions ago). There could be a way to achieve the goals mentioned in that change without thread locals. edit: |
Also facing this trying to run htop static in a flatcar linux host |
Which version of htop did you run? AFAIR there was a commit recently that changed some aspects of building |
Static linking against glibc might crash due to usage of NSS modules, e.g. via getpwuid() (see htop-dev#503). The linker also warns about it: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
observed on Ubuntu 20.04 AMD64, revision:
steps to reproduce:
result:
The text was updated successfully, but these errors were encountered: