Seg Faults on Pi-3 after upgrading to 15.1

Hal Murray <[email protected]> Fri, 19 Jun 2026 21:59:38 -0700
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <20260620045938.5694A6201DD@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
I work on NTP software - ntpsec.  I have several FreeBSD systems that I 
use for testing.  One of them is a Pi-3.  It was happy on 15.0.  After 
upgrading to 15.1, it started getting strange segfaults.  I guessed that I 
had screwed up something during the upgrade and did a fresh install.  I'm 
still getting segfaults.


I've got 2 versions of this problem, one from ntpd, and one from ntpmon 
which is a python program.  The python version gets a core dump rather 
than catching the segfault and printing something helpful.  gdb on the 
core dump doesn't have a stack to work with.  running python under gdb 
gets to a working gdb and a stack.

In both cases, we are calling inet_ntop which calls sprintf which calls 
vsprintf which dies.

#0  vsprintf (str=0xffffffffd432 "a460:4b60::1:71", fmt=0x40c484f5 "%x",
    ap=...) at /usr/src/lib/libc/stdio/vsprintf.c:67
#1  0x0000000040d31090 in sprintf (
    str=str@entry=0xffffffffd432 "a460:4b60::1:71",
    fmt=fmt@entry=0x40c484f5 "%x") at /usr/src/lib/libc/stdio/sprintf.c:55
#2  0x0000000040cdecf4 in inet_ntop6 (src=0x414b4378 "&", dst=<optimized 
out>,
    size=<optimized out>) at /usr/src/lib/libc/inet/inet_ntop.c:174
#3  __inet_ntop (af=<optimized out>, af@entry=28, src=src@entry=0x414b4378,
    dst=dst@entry=0x281c40 <lib_getbuf.lib_stringbuf+1408> "",
    size=size@entry=128) at /usr/src/lib/libc/inet/inet_ntop.c:59
#4  0x000000000024f578 in socktoa_r (sock=0x414b4370,
    buf=0x281c40 <lib_getbuf.lib_stringbuf+1408> "", 
buflen=buflen@entry=128)
    at ../../libntp/socktoa.c:54

Note the af@entry to inet_ntop.  It was called with 10 == AF_INET6

Our code that calls inet_ntop is passed a pointer to a union sockaddr_in 
and socaddr_in6.  It does a switch on the AF.  The stack shows the call 
from the AF_INET6 branch.  inet_ntop soes a similar switch to get to 
inet_ntop6.  So that 28 in af@entry is bogus.  But the storage for the 
parameter that was passed in now has a 28.  Maybe gdb is reaching back 
that far.

Has anybody seen troubles on a Pi-3?  What can I do to help?  ...

No troubles yet with 15.1 on a couple of amd64 systems.

I can reproduce this in 5 or 10 minutes.

This is not a busy system.  It's only running ntpd and ntpmon.  ntpd has 
10 servers so that's a pair of packets every 6 seconds.   ntpmon will add 
a burst of a few packets every 32 seconds.

There is also a monitoring program that writes a line to a log file every 
minute with temperature, drift, and load average.



-- 
These are my opinions.  I hate spam.