Hi, from the debian-hurd IRC, with inlined comments: (11:03:58) mjt: hello. it looks like hurd-i386 is the only arch where my one-line build-test program fails -- see https://buildd.debian.org/status/package.php?p=busybox
Checking if libc can produce working static binaries echo 'int main(void) { return getpwnam("root") ? 0 : 1; }' > build/test754813.c cc -static -o build/test754813 build/test754813.c /tmp/ccKyLKAT.o: In function `main': test754813.c:(.text+0x1a): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Segmentation fault E: your libc does not produce working statically linked binaries E: glibc-2.19 is known to have this bug: http://bugs.debian.org/754813 E: and https://sourceware.org/bugzilla/show_bug.cgi?id=17250 E: please update your libc (11:04:07) mjt: what should I do with that? (11:23:09) srs: mjt: I get the same error message on GNU/Linux too (11:23:32) mjt: gnu_srs: which error message? segmentation fault? (11:23:44) mjt: it is the sigsegv which is problematic, not the gcc warning (11:23:52) srs: test754813.c:(.text+0xf): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking (11:24:04) mjt: yes, that's expected. now run the binary. (11:24:13) mjt: on hurd it sigsegvs (11:25:52) srs: You are right: on Linux: echo $?: 1, on Hurd a segfault (11:26:13) mjt: heh. your libc on linux is broken too :) Fixed for Linux in glibc-2.19-12, I have 2.19-11 installed. (11:26:34) mjt: (the whole thing is a test for #754813) (11:26:39) zwiebelbot: (notice) Debian#754813: libc6 version 2.19 breaks NSS loading for static binaries - https://bugs.debian.org/754813 (11:27:13) mjt: but that doesn't matter, the prob is the segfault (11:28:37) srs: seems to be an infinite loop, the gdb backtrace is repeating over and over (11:32:53) srs: youpi: http://paste.debian.net/131738/ Partial gdb output: (gdb) run [New Thread 19835.10] Program received signal SIGSEGV, Segmentation fault. __mach_port_mod_refs (task=0, name=131212, right=1, delta=-1) at .../hurd-i386-libc/mach/RPC_mach_port_mod_refs.c:48 (gdb) thread apply all bt Thread 5 (Thread 19835.10): #0 0x080a51bc in mach_msg_trap () #1 0x0809e323 in mach_msg () #2 0x080a530e in mach_msg_server_timeout () #3 0x080a53df in mach_msg_server () #4 0x0809ef16 in _hurd_msgport_receive () #5 0x66688b92 in ?? () Thread 4 (Thread 19835.9): #0 __mach_port_mod_refs (task=0, name=131212, right=1, delta=-1) .../hurd-i386-libc/mach/RPC_mach_port_mod_refs.c:48 #1 0x0107f57a in __mig_dealloc_reply_port (arg=131212) at ../sysdeps/mach/hurd/mig-reply.c:46 #2 0x01253714 in __mach_port_mod_refs (task=0, name=131211, right=1, delta=-1) at .../hurd-i386-libc/mach/RPC_mach_port_mod_refs.c:137 #3 0x0107f57a in __mig_dealloc_reply_port (arg=131211) at ../sysdeps/mach/hurd/mig-reply.c:46 #4 0x01253714 in __mach_port_mod_refs (task=0, name=131210, right=1, delta=-1) at .../hurd-i386-libc/mach/RPC_mach_port_mod_refs.c:137 <repeating over and over> (13:53:58) srs: youpi: rpctrace ./test754813: http://paste.debian.net/131758/ Tail of rpctrace: 114<--127(pid-1)-> 2400 ( thread109(pid2632) task107(pid2632) 1 2 4060) ...126 116<--121(pid2632)->proc_dostop_request ( thread112(pid2632)) = 0 64<--119(pid2632)->dir_lookup ("servers/crash" 0 0) = 0 1 "" 110<--132(pid2632) task107(pid2632)->mach_port_mod_refs (pn{ 6} 0 1) = 0 87<--118(pid2632)->dir_mkfile (18 384) = 0 136<--135(pid2632) 110<--132(pid2632)->crash_dump_task ( task107(pid2632) 136<--135(pid2632) 11 2 2 1 2 4060 94<--122(pid2632)) ...111 126-> 71 (); 111... = 0 Child 2632 Segmentation fault (14:04:32) mjt: wow (14:07:30) youpi: gnu_srs: I had noticed it and kept it in my mbox yes (thus the build-attempted state, not failed) (14:07:55) youpi: this is probably an issue with symbols (14:08:13) youpi: for some functions we have actually two versions (14:08:25) youpi: one which makes an RPC, and one which makes a systemcall (14:08:43) youpi: RPC code is supposed to use only the versions that make a systemcall (14:08:50) youpi: but apparently that's not the case here (14:09:08) youpi: and thus RPC code use an RPC, i.e. the RPC code, which uses an RPC, etc. etc. Can anybody help with ideas on how to find this bug? Thanks!