After installing nfs-utils, I noticed that there are two versions of rpcinfo: 1) /usr/sbin/rpcinfo (by glibc-2.13-r1) 2) /sbin/rpcinfo (by rpcbind-0.2.0) Reproducible: Always Steps to Reproduce: 1.Install nfs-utils 2.ls -l /usr/sbin/rpcinfo 3.ls -l /sbin/rpcinfo /usr/sbin/rpcinfo (from glibc) does not seem to work as expected, e.g.: $ rpcinfo -p localhost Segmentation fault /sbin/rpcinfo (from rpcbind) seems to work fine.
glibc rpcinfo works just fine for me. run it through gdb and find out where it is segfaulting.
(In reply to comment #1) > glibc rpcinfo works just fine for me. run it through gdb and find out where it > is segfaulting. > OK, I will do that. But my main concern is that there are two instances of rpcinfo after installing nfs-utils.
(In reply to comment #1) > glibc rpcinfo works just fine for me. run it through gdb and find out where it > is segfaulting. > I still have to learn how to get binaries without any optimization. So, what I have so far is a gdb session with optimized out values. My guess is that glibc rpcinfo has problems with IPv6, because that is what I am currently actively playing with: (gdb) run -p localhost Starting program: /usr/sbin/rpcinfo -p localhost Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b51e9f in xdr_u_long (xdrs=<value optimized out>, ulp=0x100007f) at xdr.c:197 197 *ulp = (uint32_t) tmp; (gdb) where #0 0x00007ffff7b51e9f in xdr_u_long (xdrs=<value optimized out>, ulp=0x100007f) at xdr.c:197 #1 0x00007ffff7b4e2c9 in xdr_pmap (xdrs=0x6055a8, regs=0x100007f) at pmap_prot.c:46 #2 0x00007ffff7b53700 in xdr_reference (xdrs=0x6055a8, pp=0x7fffffffdd60, size=<value optimized out>, proc=<value optimized out>) at xdr_ref.c:87 #3 0x00007ffff7b4e39b in xdr_pmaplist (xdrs=0x6055a8, rp=0x7fffffffdd60) at pmap_prot2.c:106 #4 0x00007ffff7b4c7fe in clnttcp_call (h=0x6056d0, proc=4, xdr_args=0x400fd0 <xdr_void@plt>, args_ptr=0x0, xdr_results=0x4010d0 <xdr_pmaplist@plt>, results_ptr=0x7fffffffdd60 "\177", timeout=...) at clnt_tcp.c:312 #5 0x0000000000401b5c in pmapdump (argc=<value optimized out>, argv=0x7fffffffde88) at rpcinfo.c:568 #6 main (argc=<value optimized out>, argv=0x7fffffffde88) at rpcinfo.c:175
i'm not terribly worried about the same binary being installed. rcpbind's rpcinfo supports the same arguments as glibc and produces the same output. which isnt too surprising considering they have the same source code base. long term, glibc is no longer developing its rpc stack.
I have some more information. When I ebuild glibc, there are two versions of rpcinfo in /var/tmp/portage/...: /var/tmp/portage/sys-libs/glibc-2.13-r1/work/build-amd64-x86_64-pc-linux-gnu-nptl/sunrpc/rpcinfo /var/tmp/portage/sys-libs/glibc-2.13-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/sunrpc/rpcinfo The x86 one works fine, the amd64 one segfaults. I still was not able to produce a binary that I can inspect with gdb without "optimized out values"...
Next update: I managed to compile rpcinfo (build-amd64-x86_64-pc-linux-gnu-nptl) without optimization and that version does not produce a segfault. I then played with the compiler flags and when I remove only the option "-fno-strict-aliasing" (leaving -O2 as is), rpcinfo works as expected.
glibc-2.14 no longer installs rpcinfo
