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

Jun 20, 2026 07:00:03 Hal Murray <[email protected]>:

>
> I work on NTP software - ntpsec.=C2=A0 I have several FreeBSD systems tha=
t I
> use for testing.=C2=A0 One of them is a Pi-3.=C2=A0 It was happy on 15.0.=
=C2=A0 After
> upgrading to 15.1, it started getting strange segfaults.=C2=A0 I guessed =
that I
> had screwed up something during the upgrade and did a fresh install.=C2=
=A0 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.=C2=A0 The python version gets a core dump rath=
er
> than catching the segfault and printing something helpful.=C2=A0 gdb on t=
he
> core dump doesn't have a stack to work with.=C2=A0 running python under g=
db
> 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=C2=A0 vsprintf (str=3D0xffffffffd432 "a460:4b60::1:71", fmt=3D0x40c484=
f5 "%x",
> =C2=A0=C2=A0=C2=A0 ap=3D...) at /usr/src/lib/libc/stdio/vsprintf.c:67
> #1=C2=A0 0x0000000040d31090 in sprintf (
> =C2=A0=C2=A0=C2=A0 str=3Dstr@entry=3D0xffffffffd432 "a460:4b60::1:71",
> =C2=A0=C2=A0=C2=A0 fmt=3Dfmt@entry=3D0x40c484f5 "%x") at /usr/src/lib/lib=
c/stdio/sprintf.c:55
> #2=C2=A0 0x0000000040cdecf4 in inet_ntop6 (src=3D0x414b4378 "&", dst=3D<o=
ptimized
> out>,
> =C2=A0=C2=A0=C2=A0 size=3D<optimized out>) at /usr/src/lib/libc/inet/inet=
_ntop.c:174
> #3=C2=A0 __inet_ntop (af=3D<optimized out>, af@entry=3D28, src=3Dsrc@entr=
y=3D0x414b4378,
> =C2=A0=C2=A0=C2=A0 dst=3Ddst@entry=3D0x281c40 <lib_getbuf.lib_stringbuf+1=
408> "",
> =C2=A0=C2=A0=C2=A0 size=3Dsize@entry=3D128) at /usr/src/lib/libc/inet/ine=
t_ntop.c:59
> #4=C2=A0 0x000000000024f578 in socktoa_r (sock=3D0x414b4370,
> =C2=A0=C2=A0=C2=A0 buf=3D0x281c40 <lib_getbuf.lib_stringbuf+1408> "",
> buflen=3Dbuflen@entry=3D128)
> =C2=A0=C2=A0=C2=A0 at ../../libntp/socktoa.c:54
>
> Note the af@entry to inet_ntop.=C2=A0 It was called with 10 =3D=3D AF_INE=
T6
>
> Our code that calls inet_ntop is passed a pointer to a union sockaddr_in
> and socaddr_in6.=C2=A0 It does a switch on the AF.=C2=A0 The stack shows =
the call
> from the AF_INET6 branch.=C2=A0 inet_ntop soes a similar switch to get to
> inet_ntop6.=C2=A0 So that 28 in af@entry is bogus.=C2=A0 But the storage =
for the
> parameter that was passed in now has a 28.=C2=A0 Maybe gdb is reaching ba=
ck
> that far.
>
> Has anybody seen troubles on a Pi-3?=C2=A0 What can I do to help?=C2=A0 .=
..
>
Hi!

Mostly a shot in the dark, not a knowledgeble answer.
Does the codepath involves taking a pointer to a field of a packed structur=
e?
The new llvm21 had some compile time errors/warnings about such pointers af=
ter the import...

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