Re: Seg Faults on Pi-3 after upgrading to 15.1

W dniu 2026-06-20 06:59, Hal Murray napisał(a):
> 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.

I can confirm a similar issue with the Pine64 LTS board. A lot of 
segfaults in dmesg:

pid 2134 (python3.11), jid 0, uid 1001: exited on signal 11 (core 
dumped)
pid 2851 (pkg), jid 0, uid 0: exited on signal 11 (core dumped)
pid 4634 (python3.11), jid 0, uid 1001: exited on signal 11 (core 
dumped)
pid 5789 (pkg), jid 0, uid 0: exited on signal 11 (core dumped)
pid 8580 (pkg), jid 0, uid 0: exited on signal 11 (core dumped)
pid 9996 (python3.11), jid 0, uid 1001: exited on signal 11 (no core 
dump - coredumpsize limit is 0)

But I have no idea how to fix this..

I have another SBC, Pine H64, which works on 15.1 without issues. Both 
boards have an Allwinner chip, but different models.