One-line build-test from busybox statically built segfaults on GNU/Hurd

[Svante Signell]

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!