On Sun, Sep 14, 2025 at 9:15 PM Zaphod Beeblebrox <[email protected]> wrote: > > OK. Thanks. rpcbind used to be running it wasn't. Ran rpcbind -d manually > and then ran (same machine) rpcinfo localhost. rpcbind coredumps. GDB says: > > (gdb) bt > #0 ?? () at /usr/src/lib/libc/amd64/string/strlen.S:95 from /lib/libc.so.7 > #1 0x00001d9c3c5273a8 in xdr_string (xdrs=xdrs@entry=0x3ba5fb06f808, > cpp=cpp@entry=0x3ba5fb047460, maxsize=maxsize@entry=9000) > at /usr/src/lib/libc/xdr/xdr.c:701 > #2 0x00001d9c3c51b841 in xdr_rpcb (xdrs=0x3ba5fb06f808, objp=0x3ba5fb047450) > at /usr/src/lib/libc/rpc/rpcb_prot.c:63 > #3 0x00001d9c3c528df2 in xdr_reference (xdrs=xdrs@entry=0x3ba5fb06f808, > pp=pp@entry=0x1d9418ba7140 <list_rbl>, > size=size@entry=40, proc=proc@entry=0x1d9c3c51b7f0 <xdr_rpcb>) at > /usr/src/lib/libc/xdr/xdr_reference.c:92 > #4 0x00001d9c3c51b943 in xdr_rpcblist_ptr (xdrs=0x3ba5fb06f808, > rp=0x1d9418ba7140 <list_rbl>) > at /usr/src/lib/libc/rpc/rpcb_prot.c:124 > #5 0x00001d9c3c5205e4 in svc_vc_reply (xprt=0x3ba5fb0208c0, > msg=0x1d9c39a3d618) at /usr/src/lib/libc/rpc/svc_vc.c:646 > #6 0x00001d9c3c51c7ee in svc_sendreply (xprt=0x0, xprt@entry=0x3ba5fb0208c0, > xdr_results=xdr_results@entry=0x1d9c3c51b870 <xdr_rpcblist_ptr>, > xdr_location=0x2328) at /usr/src/lib/libc/rpc/svc.c:368 > #7 0x00001d9418ba0f52 in rpcb_service_3 (rqstp=0x1d9c39a3d740, > transp=0x3ba5fb0208c0) > at /usr/src/usr.sbin/rpcbind/rpcb_svc.c:175 > #8 0x00001d9c3c51d08d in svc_getreq_common (fd=<optimized out>) at > /usr/src/lib/libc/rpc/svc.c:664 > #9 0x00001d9c3c51d118 in svc_getreq_poll (pfdp=pfdp@entry=0x1d9c39a3dcf0, > pollretval=1) at /usr/src/lib/libc/rpc/svc.c:732 > #10 0x00001d9418ba3069 in my_svc_run () at > /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 > #11 0x00001d9418b9f835 in main (argc=<optimized out>, argv=0x1d9c39a40000) at > /usr/src/usr.sbin/rpcbind/rpcbind.c:286 Yea, its busted alright. I reproduced the crash. It appears that the r_addr field has not been set to a string. (My current guess is that commit d50fc4b broke it for the netlink case.)
I'll poke away at it and post if/when I have a patch for testing. If you just want to work around it, you could try a NFSv4 mount, which doesn't use rpcbind. rick > > > On Sun, Sep 14, 2025 at 8:51 PM Rick Macklem <[email protected]> wrote: >> >> On Fri, Sep 12, 2025 at 7:55 PM Zaphod Beeblebrox <[email protected]> wrote: >> > >> > My overall goal is to have a FreeBSD workstation before Windows 10 dies. >> > That's coming up pretty quickly, so I've been testing. Because FreeBSD's >> > proton support is very much dependant on 15-CURRENT, I upgraded both the >> > new workstation and my poudriere box to the 15-current about 2 weeks ago. >> > >> > Now... normally, when the workstation boots, half a dozen NFS mounts to >> > the poudriere server (also fileserver) occur. This has been the config >> > since ... well... since back to FreeBSD 4 or so. >> > >> > My workstation's fstab has lines of the form: >> > >> > vr:/vr1/tmp /d/vr/tmp nfs rw,-3,-T,-l,-i,-b 0 0 >> > >> > 'vr' being the hostname and so on. On vr, >> > [2:31:331]root@vr:~> zfs get sharenfs vr1/tmp >> > NAME PROPERTY VALUE SOURCE >> > vr1/tmp sharenfs -maproot=nobody ump run local >> > >> > Now... for some number of upgrades, this spits out lines like "-i >> > deprecated, use -o intr" ... which it still does --- but then it hangs ... >> > for one NFS time out and it moves onto the next share. No errors on >> > either the client or the server. What's changed here? Both machines were >> > working before the upgrade from 14.3 to 15-c. >> >> Those options are from the Jurassic period, but they should still work, >> afaik. >> >> I suspect your mount problem is something related to networking >> (firewall or ipv4 vs ipv6 or ???). Note that NFSv3 does need rpcbind >> to be working. >> >> rick
