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.