Was just thinking about this some more and was surprised at the segmentation fault, as I was expecting a general protection fault if the instruction is wrong, and sure enough, dmesg has:
[96649.067868] traps: rpcinfo[9287] general protection ip:7f07f4e59218 sp:7fff54e78cf8 error:0 in libpthread-2.19.so[7f07f4e48000+18000] Sincerely, -Alex On Fri, Jun 13, 2014 at 12:32 AM, Alex Chernyakhovsky <acher...@mit.edu> wrote: > I've done a bit of digging: > - rebuilding rpcbind has no effect > - rebuilding libtirpc has no effect > > The crash appears to be occuring inside of libpthread, on a TSX-only code > path: > > Program received signal SIGSEGV, Segmentation fault. > > __lll_unlock_elision (lock=0x7ffff7ddafe0 <authnone_lock>, private=0) > at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 > 29 ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such > file or directory. > (gdb) bt > #0 __lll_unlock_elision (lock=0x7ffff7ddafe0 <authnone_lock>, > private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 > #1 0x00007ffff7bbb9c1 in ?? () from /lib/x86_64-linux-gnu/libtirpc.so.1 > #2 0x00007ffff7bc084b in ?? () from /lib/x86_64-linux-gnu/libtirpc.so.1 > #3 0x0000000000403cda in rpcbdump (dumptype=dumptype@entry=8, > netid=netid@entry=0x0, argc=<optimized out>, argv=<optimized out>) > at src/rpcinfo.c:849 > #4 0x0000000000401a0b in main (argc=1, argv=0x7fffffffe418) at > src/rpcinfo.c:311 > > elision-unlock.c:29 corresponds to an _xend() function call, which > seems to inline to the xend opcode: > > (gdb) disas > Dump of assembler code for function __lll_unlock_elision: > 0x00007ffff79a7200 <+0>: mov (%rdi),%eax > 0x00007ffff79a7202 <+2>: mov %rdi,%rdx > 0x00007ffff79a7205 <+5>: test %eax,%eax > 0x00007ffff79a7207 <+7>: je 0x7ffff79a7218 > <__lll_unlock_elision+24> > 0x00007ffff79a7209 <+9>: lock decl (%rdx) > 0x00007ffff79a720c <+12>: jne 0x7ffff79a721e <_L_unlock_13> > 0x00007ffff79a720e <+14>: xor %eax,%eax > 0x00007ffff79a7210 <+16>: retq > 0x00007ffff79a7211 <+17>: nopl 0x0(%rax) > => 0x00007ffff79a7218 <+24>: xend > 0x00007ffff79a721b <+27>: xor %eax,%eax > 0x00007ffff79a721d <+29>: retq > End of assembler dump. > > My processor is a Intel E3-1240v3, which has TSX: > > $ grep -o rtm /proc/cpuinfo > rtm > rtm > rtm > rtm > rtm > rtm > rtm > rtm > > Unfortunately, it looks like eglibc currently in jessie is new enough > to have TSX support, but not new enough for the environment variables > to disable it, so I cannot disable it that way. However, making the > binary setuid root causes it to work: > > sudo chown root:root rpcinfo > sudo chmod +s rpcinfo > > ./rpcinfo > program version netid address service owner > 100000 4 tcp6 ::.0.111 portmapper superuser > 100000 3 tcp6 ::.0.111 portmapper superuser > 100000 4 udp6 ::.0.111 portmapper superuser > 100000 3 udp6 ::.0.111 portmapper superuser > 100000 4 tcp 0.0.0.0.0.111 portmapper superuser > 100000 3 tcp 0.0.0.0.0.111 portmapper superuser > 100000 2 tcp 0.0.0.0.0.111 portmapper superuser > 100000 4 udp 0.0.0.0.0.111 portmapper superuser > 100000 3 udp 0.0.0.0.0.111 portmapper superuser > 100000 2 udp 0.0.0.0.0.111 portmapper superuser > 100000 4 local /run/rpcbind.sock portmapper superuser > 100000 3 local /run/rpcbind.sock portmapper superuser > > At this point, I mildly suspect libc. > > Sincerely, > -Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
