NetBSD Problem Report #59035
From martin@duskware.de Tue Jan 28 11:20:46 2025
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id AEE101A923A
for <gnats-bugs@gnats.NetBSD.org>; Tue, 28 Jan 2025 11:20:46 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: new named(8) crashes at startup on evbarmv5
X-Send-Pr-Version: 3.95
>Number: 59035
>Category: bin
>Synopsis: new named(8) crashes at startup on evbarmv5
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 28 11:25:00 +0000 2025
>Last-Modified: Sun Feb 16 07:30:01 +0000 2025
>Originator: Martin Husemann
>Release: NetBSD 10.99.12
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD unpluged.duskware.de 10.99.12 NetBSD 10.99.12 (UNPLUGED) #621: Tue Jan 28 10:16:08 CET 2025 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/evbarm/compile/UNPLUGED evbarm
Architecture: earmv5
Machine: evbarm
>Description:
After updating to todays -current the named on this machine does not start
any more.
gdb named named.core
GNU gdb (GDB) 15.1
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "armv7--netbsdelf-eabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from named...
Reading symbols from /usr/libdata/debug//usr/sbin/named.debug...
[New process 351]
[New process 1383]
[New process 292]
[New process 1437]
Core was generated by `named'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000504c0 in compat_futex_noasync (uaddr=0xbb2952a8, op=-1169994232, val=256, timeout=<optimized out>,
uaddr2=0x4, val3=0)
at /work/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/compat_futex.c:71
unfortunately it can't backtrace from there.
(gdb) info reg
r0 0xbb514040 3142664256
r1 0xbbd40208 3151233544
r2 0x10000 65536
r3 0x0 0
r4 0xbb2952a8 3140047528
r5 0x100 256
r6 0x40 64
r7 0xbbd40208 3151233544
r8 0xba434e08 3124973064
r9 0xbb2c253c 3140232508
r10 0xbb2c2658 3140232792
r11 0x0 0
r12 0x920f0 598256
sp 0xbfffe688 0xbfffe688
lr 0x504c0 328896
pc 0x504c0 0x504c0 <compat_futex_noasync+184>
cpsr 0x20000010 536870928
Dump of assembler code for function compat_futex_noasync:
0x00050408 <+0>: push {r4, r5, r6, r7, r8, r9, lr}
0x0005040c <+4>: ldr r9, [pc, #332] @ 0x50560 <compat_futex_noasync+344>
0x00050410 <+8>: sub sp, sp, #12
0x00050414 <+12>: cmp r3, #0
0x00050418 <+16>: ldr r12, [sp, #40] @ 0x28
0x0005041c <+20>: add r9, pc, r9
0x00050420 <+24>: bne 0x50540 <compat_futex_noasync+312>
0x00050424 <+28>: cmp r12, #0
0x00050428 <+32>: bne 0x50520 <compat_futex_noasync+280>
0x0005042c <+36>: ldr r3, [sp, #44] @ 0x2c
0x00050430 <+40>: cmp r3, #0
0x00050434 <+44>: bne 0x50500 <compat_futex_noasync+248>
0x00050438 <+48>: mov r4, r0
0x0005043c <+52>: mov r8, r1
0x00050440 <+56>: mov r5, r2
0x00050444 <+60>: bl 0x108f4 <__sync_synchronize@plt>
0x00050448 <+64>: ldr r3, [pc, #276] @ 0x50564 <compat_futex_noasync+348>
0x0005044c <+68>: ldr r6, [r9, r3]
0x00050450 <+72>: mov r0, r6
0x00050454 <+76>: bl 0xf250 <__libc_mutex_lock@plt>
0x00050458 <+80>: subs r7, r0, #0
0x0005045c <+84>: bne 0x504f4 <compat_futex_noasync+236>
0x00050460 <+88>: cmp r8, #0
0x00050464 <+92>: beq 0x504b4 <compat_futex_noasync+172>
0x00050468 <+96>: cmp r8, #1
0x0005046c <+100>: bne 0x504a0 <compat_futex_noasync+152>
0x00050470 <+104>: ldr r3, [pc, #240] @ 0x50568 <compat_futex_noasync+352>
0x00050474 <+108>: ldr r3, [r9, r3]
0x00050478 <+112>: mov r0, r3
0x0005047c <+116>: str r3, [sp, #4]
0x00050480 <+120>: bl 0x10f30 <__libc_cond_broadcast@plt>
0x00050484 <+124>: mov r0, r6
0x00050488 <+128>: bl 0x117f4 <__libc_mutex_unlock@plt>
0x0005048c <+132>: subs r4, r0, #0
0x00050490 <+136>: bne 0x504e4 <compat_futex_noasync+220>
0x00050494 <+140>: mov r0, r7
0x00050498 <+144>: add sp, sp, #12
0x0005049c <+148>: pop {r4, r5, r6, r7, r8, r9, pc}
0x000504a0 <+152>: bl 0xebd8 <__errno@plt>
0x000504a4 <+156>: mov r3, #22
0x000504a8 <+160>: mvn r7, #0
0x000504ac <+164>: str r3, [r0]
0x000504b0 <+168>: b 0x50484 <compat_futex_noasync+124>
0x000504b4 <+172>: ldr r3, [r4]
0x000504b8 <+176>: cmp r5, r3
0x000504bc <+180>: bne 0x50484 <compat_futex_noasync+124>
=> 0x000504c0 <+184>: ldr r3, [pc, #160] @ 0x50568 <compat_futex_noasync+352>
0x000504c4 <+188>: ldr r8, [r9, r3]
0x000504c8 <+192>: mov r1, r6
0x000504cc <+196>: mov r0, r8
0x000504d0 <+200>: bl 0x10ea0 <__libc_cond_wait@plt>
0x000504d4 <+204>: ldr r3, [r4]
0x000504d8 <+208>: cmp r3, r5
0x000504dc <+212>: beq 0x504c8 <compat_futex_noasync+192>
0x000504e0 <+216>: b 0x50484 <compat_futex_noasync+124>
0x000504e4 <+220>: bl 0xebd8 <__errno@plt>
0x000504e8 <+224>: str r4, [r0]
0x000504ec <+228>: mvn r7, #0
0x000504f0 <+232>: b 0x50494 <compat_futex_noasync+140>
0x000504f4 <+236>: bl 0xebd8 <__errno@plt>
0x000504f8 <+240>: str r7, [r0]
0x000504fc <+244>: b 0x504ec <compat_futex_noasync+228>
0x00050500 <+248>: ldr r3, [pc, #100] @ 0x5056c <compat_futex_noasync+356>
0x00050504 <+252>: ldr r2, [pc, #100] @ 0x50570 <compat_futex_noasync+360>
0x00050508 <+256>: ldr r0, [pc, #100] @ 0x50574 <compat_futex_noasync+364>
0x0005050c <+260>: mov r1, #51 @ 0x33
0x00050510 <+264>: add r3, pc, r3
0x00050514 <+268>: add r2, pc, r2
0x00050518 <+272>: add r0, pc, r0
0x0005051c <+276>: bl 0x10984 <__assert13@plt>
0x00050520 <+280>: ldr r3, [pc, #80] @ 0x50578 <compat_futex_noasync+368>
0x00050524 <+284>: ldr r2, [pc, #80] @ 0x5057c <compat_futex_noasync+372>
0x00050528 <+288>: ldr r0, [pc, #80] @ 0x50580 <compat_futex_noasync+376>
0x0005052c <+292>: mov r1, #50 @ 0x32
0x00050530 <+296>: add r3, pc, r3
0x00050534 <+300>: add r2, pc, r2
0x00050538 <+304>: add r0, pc, r0
0x0005053c <+308>: bl 0x10984 <__assert13@plt>
0x00050540 <+312>: ldr r3, [pc, #60] @ 0x50584 <compat_futex_noasync+380>
0x00050544 <+316>: ldr r2, [pc, #60] @ 0x50588 <compat_futex_noasync+384>
0x00050548 <+320>: ldr r0, [pc, #60] @ 0x5058c <compat_futex_noasync+388>
0x0005054c <+324>: mov r1, #49 @ 0x31
0x00050550 <+328>: add r3, pc, r3
0x00050554 <+332>: add r2, pc, r2
0x00050558 <+336>: add r0, pc, r0
0x0005055c <+340>: bl 0x10984 <__assert13@plt>
0x00050560 <+344>: muleq r4, r4, r2
0x00050564 <+348>: strdeq r0, [r0], -r12
0x00050568 <+352>: ldrdeq r0, [r0], -r8
0x0005056c <+356>: andeq r8, r2, r12, ror r4
0x00050570 <+360>: andeq r4, r3, r8, lsl #19
0x00050574 <+364>: andeq r8, r2, r4, lsl r4
0x00050578 <+368>: andeq r8, r2, r4, asr r4
0x0005057c <+372>: andeq r4, r3, r8, ror #18
0x00050580 <+376>: strdeq r8, [r2], -r4
0x00050584 <+380>: ldrdeq r8, [r2], -r0
0x00050588 <+384>: andeq r4, r3, r8, asr #18
0x0005058c <+388>: ldrdeq r8, [r2], -r4
End of assembler dump.
>How-To-Repeat:
not quite sure, evbearmv5 specific?
>Fix:
n/a
>Audit-Trail:
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: bin/59035: new named(8) crashes at startup on evbarmv5
Date: Tue, 28 Jan 2025 18:18:03 -0500
--Apple-Mail=_8FD8957E-16BF-4232-850A-E68F2B9AC06E
Content-Type: multipart/alternative;
boundary="Apple-Mail=_F2896C6F-CE9F-4AF4-A9F7-20BEC905BDEA"
--Apple-Mail=_F2896C6F-CE9F-4AF4-A9F7-20BEC905BDEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
For the source:
switch (op) {
case FUTEX_WAIT:
/*
* Wait until *uaddr is changed to something else than =
"val".
* Comparing *uaddr content against val figures out =
which
* thread has been awakened.
*/
while (CMM_LOAD_SHARED(*uaddr) =3D=3D val)
pthread_cond_wait(&__urcu_compat_futex_cond,
&__urcu_compat_futex_lock);
This instruction is:
.LBE2: =20
.loc 1 71 34 is_stmt 0 view .LVU35
cmp r5, r3
bne .L13
ldr r3, .L29+8
ldr r8, [r9, r3]
.LVL14:=20
.L10:
.loc 1 72 4 is_stmt 1 view .LVU36
mov r1, r6
mov r0, r8
bl __libc_cond_wait(PLT)
.LVL15:=20
and
.L29: =20
.word _GLOBAL_OFFSET_TABLE_-(.LPIC9+8)
.word __urcu_compat_futex_lock(GOT)
.word __urcu_compat_futex_cond(GOT)
.word .LC3-(.LPIC6+8)
.word .LANCHOR0-(.LPIC7+8)
.word .LC1-(.LPIC8+8)
.word .LC2-(.LPIC3+8)
.word .LANCHOR0-(.LPIC4+8)
.word .LC1-(.LPIC5+8)
.word .LC0-(.LPIC0+8)
.word .LANCHOR0-(.LPIC1+8)
.word .LC1-(.LPIC2+8)
.cfi_endproc
So it is loading __urcu_compat_futex_cond from the GOT and crashing?
Best,
christos
> On Jan 28, 2025, at 6:25=E2=80=AFAM, martin@netbsd.org =
<martin@NetBSD.org> wrote:
>=20
>> Number: 59035
>> Category: bin
>> Synopsis: new named(8) crashes at startup on evbarmv5
>> Confidential: no
>> Severity: critical
>> Priority: high
>> Responsible: bin-bug-people
>> State: open
>> Class: sw-bug
>> Submitter-Id: net
>> Arrival-Date: Tue Jan 28 11:25:00 +0000 2025
>> Originator: Martin Husemann
>> Release: NetBSD 10.99.12
>> Organization:
> The NetBSD Foundation, Inc.
>> Environment:
> System: NetBSD unpluged.duskware.de 10.99.12 NetBSD 10.99.12 =
(UNPLUGED) #621: Tue Jan 28 10:16:08 CET 2025 =
martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/evbarm/comp=
ile/UNPLUGED evbarm
> Architecture: earmv5
> Machine: evbarm
>> Description:
>=20
> After updating to todays -current the named on this machine does not =
start
> any more.
>=20
> gdb named named.core=20
> GNU gdb (GDB) 15.1
> Copyright (C) 2024 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later =
<http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "armv7--netbsdelf-eabihf".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
>=20
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from named...
> Reading symbols from /usr/libdata/debug//usr/sbin/named.debug...
> [New process 351]
> [New process 1383]
> [New process 292]
> [New process 1437]
> Core was generated by `named'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x000504c0 in compat_futex_noasync (uaddr=3D0xbb2952a8, =
op=3D-1169994232, val=3D256, timeout=3D<optimized out>,=20
> uaddr2=3D0x4, val3=3D0)
> at =
/work/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/com=
pat_futex.c:71
>=20
> unfortunately it can't backtrace from there.
>=20
> (gdb) info reg
> r0 0xbb514040 3142664256
> r1 0xbbd40208 3151233544
> r2 0x10000 65536
> r3 0x0 0
> r4 0xbb2952a8 3140047528
> r5 0x100 256
> r6 0x40 64
> r7 0xbbd40208 3151233544
> r8 0xba434e08 3124973064
> r9 0xbb2c253c 3140232508
> r10 0xbb2c2658 3140232792
> r11 0x0 0
> r12 0x920f0 598256
> sp 0xbfffe688 0xbfffe688
> lr 0x504c0 328896
> pc 0x504c0 0x504c0 <compat_futex_noasync+184>
> cpsr 0x20000010 536870928
> Dump of assembler code for function compat_futex_noasync:
> 0x00050408 <+0>: push {r4, r5, r6, r7, r8, r9, lr}
> 0x0005040c <+4>: ldr r9, [pc, #332] @ 0x50560 =
<compat_futex_noasync+344>
> 0x00050410 <+8>: sub sp, sp, #12
> 0x00050414 <+12>: cmp r3, #0
> 0x00050418 <+16>: ldr r12, [sp, #40] @ 0x28
> 0x0005041c <+20>: add r9, pc, r9
> 0x00050420 <+24>: bne 0x50540 <compat_futex_noasync+312>
> 0x00050424 <+28>: cmp r12, #0
> 0x00050428 <+32>: bne 0x50520 <compat_futex_noasync+280>
> 0x0005042c <+36>: ldr r3, [sp, #44] @ 0x2c
> 0x00050430 <+40>: cmp r3, #0
> 0x00050434 <+44>: bne 0x50500 <compat_futex_noasync+248>
> 0x00050438 <+48>: mov r4, r0
> 0x0005043c <+52>: mov r8, r1
> 0x00050440 <+56>: mov r5, r2
> 0x00050444 <+60>: bl 0x108f4 <__sync_synchronize@plt>
> 0x00050448 <+64>: ldr r3, [pc, #276] @ 0x50564 =
<compat_futex_noasync+348>
> 0x0005044c <+68>: ldr r6, [r9, r3]
> 0x00050450 <+72>: mov r0, r6
> 0x00050454 <+76>: bl 0xf250 <__libc_mutex_lock@plt>
> 0x00050458 <+80>: subs r7, r0, #0
> 0x0005045c <+84>: bne 0x504f4 <compat_futex_noasync+236>
> 0x00050460 <+88>: cmp r8, #0
> 0x00050464 <+92>: beq 0x504b4 <compat_futex_noasync+172>
> 0x00050468 <+96>: cmp r8, #1
> 0x0005046c <+100>: bne 0x504a0 <compat_futex_noasync+152>
> 0x00050470 <+104>: ldr r3, [pc, #240] @ 0x50568 =
<compat_futex_noasync+352>
> 0x00050474 <+108>: ldr r3, [r9, r3]
> 0x00050478 <+112>: mov r0, r3
> 0x0005047c <+116>: str r3, [sp, #4]
> 0x00050480 <+120>: bl 0x10f30 <__libc_cond_broadcast@plt>
> 0x00050484 <+124>: mov r0, r6
> 0x00050488 <+128>: bl 0x117f4 <__libc_mutex_unlock@plt>
> 0x0005048c <+132>: subs r4, r0, #0
> 0x00050490 <+136>: bne 0x504e4 <compat_futex_noasync+220>
> 0x00050494 <+140>: mov r0, r7
> 0x00050498 <+144>: add sp, sp, #12
> 0x0005049c <+148>: pop {r4, r5, r6, r7, r8, r9, pc}
> 0x000504a0 <+152>: bl 0xebd8 <__errno@plt>
> 0x000504a4 <+156>: mov r3, #22
> 0x000504a8 <+160>: mvn r7, #0
> 0x000504ac <+164>: str r3, [r0]
> 0x000504b0 <+168>: b 0x50484 <compat_futex_noasync+124>
> 0x000504b4 <+172>: ldr r3, [r4]
> 0x000504b8 <+176>: cmp r5, r3
> 0x000504bc <+180>: bne 0x50484 <compat_futex_noasync+124>
> =3D> 0x000504c0 <+184>: ldr r3, [pc, #160] @ 0x50568 =
<compat_futex_noasync+352>
> 0x000504c4 <+188>: ldr r8, [r9, r3]
> 0x000504c8 <+192>: mov r1, r6
> 0x000504cc <+196>: mov r0, r8
> 0x000504d0 <+200>: bl 0x10ea0 <__libc_cond_wait@plt>
> 0x000504d4 <+204>: ldr r3, [r4]
> 0x000504d8 <+208>: cmp r3, r5
> 0x000504dc <+212>: beq 0x504c8 <compat_futex_noasync+192>
> 0x000504e0 <+216>: b 0x50484 <compat_futex_noasync+124>
> 0x000504e4 <+220>: bl 0xebd8 <__errno@plt>
> 0x000504e8 <+224>: str r4, [r0]
> 0x000504ec <+228>: mvn r7, #0
> 0x000504f0 <+232>: b 0x50494 <compat_futex_noasync+140>
> 0x000504f4 <+236>: bl 0xebd8 <__errno@plt>
> 0x000504f8 <+240>: str r7, [r0]
> 0x000504fc <+244>: b 0x504ec <compat_futex_noasync+228>
> 0x00050500 <+248>: ldr r3, [pc, #100] @ 0x5056c =
<compat_futex_noasync+356>
> 0x00050504 <+252>: ldr r2, [pc, #100] @ 0x50570 =
<compat_futex_noasync+360>
> 0x00050508 <+256>: ldr r0, [pc, #100] @ 0x50574 =
<compat_futex_noasync+364>
> 0x0005050c <+260>: mov r1, #51 @ 0x33
> 0x00050510 <+264>: add r3, pc, r3
> 0x00050514 <+268>: add r2, pc, r2
> 0x00050518 <+272>: add r0, pc, r0
> 0x0005051c <+276>: bl 0x10984 <__assert13@plt>
> 0x00050520 <+280>: ldr r3, [pc, #80] @ 0x50578 =
<compat_futex_noasync+368>
> 0x00050524 <+284>: ldr r2, [pc, #80] @ 0x5057c =
<compat_futex_noasync+372>
> 0x00050528 <+288>: ldr r0, [pc, #80] @ 0x50580 =
<compat_futex_noasync+376>
> 0x0005052c <+292>: mov r1, #50 @ 0x32
> 0x00050530 <+296>: add r3, pc, r3
> 0x00050534 <+300>: add r2, pc, r2
> 0x00050538 <+304>: add r0, pc, r0
> 0x0005053c <+308>: bl 0x10984 <__assert13@plt>
> 0x00050540 <+312>: ldr r3, [pc, #60] @ 0x50584 =
<compat_futex_noasync+380>
> 0x00050544 <+316>: ldr r2, [pc, #60] @ 0x50588 =
<compat_futex_noasync+384>
> 0x00050548 <+320>: ldr r0, [pc, #60] @ 0x5058c =
<compat_futex_noasync+388>
> 0x0005054c <+324>: mov r1, #49 @ 0x31
> 0x00050550 <+328>: add r3, pc, r3
> 0x00050554 <+332>: add r2, pc, r2
> 0x00050558 <+336>: add r0, pc, r0
> 0x0005055c <+340>: bl 0x10984 <__assert13@plt>
> 0x00050560 <+344>: muleq r4, r4, r2
> 0x00050564 <+348>: strdeq r0, [r0], -r12
> 0x00050568 <+352>: ldrdeq r0, [r0], -r8
> 0x0005056c <+356>: andeq r8, r2, r12, ror r4
> 0x00050570 <+360>: andeq r4, r3, r8, lsl #19
> 0x00050574 <+364>: andeq r8, r2, r4, lsl r4
> 0x00050578 <+368>: andeq r8, r2, r4, asr r4
> 0x0005057c <+372>: andeq r4, r3, r8, ror #18
> 0x00050580 <+376>: strdeq r8, [r2], -r4
> 0x00050584 <+380>: ldrdeq r8, [r2], -r0
> 0x00050588 <+384>: andeq r4, r3, r8, asr #18
> 0x0005058c <+388>: ldrdeq r8, [r2], -r4
> End of assembler dump.
>=20
>=20
>> How-To-Repeat:
> not quite sure, evbearmv5 specific?
>=20
>> Fix:
> n/a
--Apple-Mail=_F2896C6F-CE9F-4AF4-A9F7-20BEC905BDEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div>For the =
source:</div><div><br></div><div><div> switch =
(op) {</div><div> case =
FUTEX_WAIT:</div><div> =
/*</div><div> =
* Wait until *uaddr is changed to something else than =
"val".</div><div> =
* Comparing *uaddr content against val figures out =
which</div><div> =
* thread has been awakened.</div><div> =
*/</div><div> =
while (CMM_LOAD_SHARED(*uaddr) =3D=3D =
val)</div><div> =
<font color=3D"#ff2600"> =
pthread_cond_wait(&__urcu_compat_futex_cond,</font></div><div> =
=
=
&__urcu_compat_futex_lock);</div></div><div><br></div>This =
instruction is:<div><br></div><div> .LBE2: <div> =
.loc 1 71 34 is_stmt 0 view .LVU35</div><div> =
cmp r5, r3</div><div> =
bne .L13</div><div> <font =
color=3D"#ff2600"> ldr r3, .L29+8</font></div><div> =
ldr r8, [r9, =
r3]</div><div>.LVL14: </div><div>.L10:</div><div> =
.loc 1 72 4 is_stmt 1 view .LVU36</div><div> =
mov r1, r6</div><div> =
mov r0, r8</div><div> bl =
=
__libc_cond_wait(PLT)</div><div>.LVL15: </div><div><br></div><d=
iv>and</div><div><br></div><div><div>.L29: </div><div> =
.word =
_GLOBAL_OFFSET_TABLE_-(.LPIC9+8)</div><div> =
.word __urcu_compat_futex_lock(GOT)</div><div> =
<font color=3D"#ff2600"> .word =
__urcu_compat_futex_cond(GOT)</font></div><div> =
.word .LC3-(.LPIC6+8)</div><div> =
.word .LANCHOR0-(.LPIC7+8)</div><div> =
.word .LC1-(.LPIC8+8)</div><div> =
.word .LC2-(.LPIC3+8)</div><div> =
.word .LANCHOR0-(.LPIC4+8)</div><div> =
.word .LC1-(.LPIC5+8)</div><div> =
.word .LC0-(.LPIC0+8)</div><div> =
.word .LANCHOR0-(.LPIC1+8)</div><div> =
.word .LC1-(.LPIC2+8)</div><div> =
.cfi_endproc</div></div><div><br></div><div>So it is loading =
__urcu_compat_futex_cond from the GOT and =
crashing?</div><div><br></div><div>Best,</div><div><br></div><div>christos=
</div><div><br><blockquote type=3D"cite"><div>On Jan 28, 2025, at =
6:25=E2=80=AFAM, martin@netbsd.org <martin@NetBSD.org> =
wrote:</div><br class=3D"Apple-interchange-newline"><div><div><blockquote =
type=3D"cite">Number: =
59035<br>Category: =
bin<br>Synopsis: =
new named(8) crashes at startup on =
evbarmv5<br>Confidential: no<br>Severity: =
critical<br>Priority: =
high<br>Responsible: =
bin-bug-people<br>State: =
open<br>Class: =
sw-bug<br>Submitter-=
Id: net<br>Arrival-Date: Tue Jan 28 11:25:00 =
+0000 2025<br>Originator: Martin =
Husemann<br>Release: NetBSD =
10.99.12<br>Organization:<br></blockquote>The NetBSD Foundation, =
Inc.<br><blockquote type=3D"cite">Environment:<br></blockquote>System: =
NetBSD unpluged.duskware.de 10.99.12 NetBSD 10.99.12 (UNPLUGED) #621: =
Tue Jan 28 10:16:08 CET 2025 =
martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/evbarm/comp=
ile/UNPLUGED evbarm<br>Architecture: earmv5<br>Machine: =
evbarm<br><blockquote type=3D"cite">Description:<br></blockquote><br>After=
updating to todays -current the named on this machine does not =
start<br>any more.<br><br>gdb named named.core <br>GNU gdb (GDB) =
15.1<br>Copyright (C) 2024 Free Software Foundation, Inc.<br>License =
GPLv3+: GNU GPL version 3 or later =
<http://gnu.org/licenses/gpl.html><br>This is free software: you =
are free to change and redistribute it.<br>There is NO WARRANTY, to the =
extent permitted by law.<br>Type "show copying" and "show warranty" for =
details.<br>This GDB was configured as =
"armv7--netbsdelf-eabihf".<br>Type "show configuration" for =
configuration details.<br>For bug reporting instructions, please =
see:<br><https://www.gnu.org/software/gdb/bugs/>.<br>Find the GDB =
manual and other documentation resources online at:<br> =
<http://www.gnu.org/software/gdb/documentation/>.<=
br><br>For help, type "help".<br>Type "apropos word" to search for =
commands related to "word"...<br>Reading symbols from =
named...<br>Reading symbols from =
/usr/libdata/debug//usr/sbin/named.debug...<br>[New process 351]<br>[New =
process 1383]<br>[New process 292]<br>[New process 1437]<br>Core was =
generated by `named'.<br>Program terminated with signal SIGSEGV, =
Segmentation fault.<br>#0 0x000504c0 in compat_futex_noasync =
(uaddr=3D0xbb2952a8, op=3D-1169994232, val=3D256, timeout=3D<optimized =
out>, <br> uaddr2=3D0x4, val3=3D0)<br> =
at =
/work/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/com=
pat_futex.c:71<br><br>unfortunately it can't backtrace from =
there.<br><br>(gdb) info reg<br>r0 =
0x=
bb514040 =
3142664256<br>r1 =
0x=
bbd40208 =
3151233544<br>r2 =
0x=
10000 =
65=
536<br>r3 =
0x=
0 =
&n=
bsp; 0<br>r4 =
0x=
bb2952a8 =
3140047528<br>r5 =
0x=
100 =
&n=
bsp; 256<br>r6 =
0x=
40 =
&n=
bsp; 64<br>r7 =
0x=
bbd40208 =
3151233544<br>r8 =
0x=
ba434e08 =
3124973064<br>r9 =
0x=
bb2c253c =
3140232508<br>r10 =
0xbb2c26=
58 =
3140232792<br>r11 =
0x0 =
&n=
bsp; 0<br>r12 =
0x920f0 =
59=
8256<br>sp =
0x=
bfffe688 =
0xbfffe688<br>lr =
0x=
504c0 =
32=
8896<br>pc =
0x=
504c0 =
0x=
504c0 <compat_futex_noasync+184><br>cpsr =
0x20000010 =
536870928<br>Dump =
of assembler code for function compat_futex_noasync:<br> =
0x00050408 <+0>: push =
{r4, r5, r6, r7, r8, r9, lr}<br> =
0x0005040c <+4>: ldr =
r9, [pc, #332] @ 0x50560 =
<compat_futex_noasync+344><br> 0x00050410 <+8>: =
sub sp, sp, #12<br> =
0x00050414 <+12>: cmp =
r3, #0<br> 0x00050418 <+16>: =
ldr r12, [sp, #40] @ =
0x28<br> 0x0005041c <+20>: add =
r9, pc, r9<br> 0x00050420 =
<+24>: bne 0x50540 =
<compat_futex_noasync+312><br> 0x00050424 <+28>: =
cmp r12, #0<br> =
0x00050428 <+32>: bne =
0x50520 <compat_futex_noasync+280><br> =
0x0005042c <+36>: ldr =
r3, [sp, #44] @ 0x2c<br> =
0x00050430 <+40>: cmp =
r3, #0<br> 0x00050434 <+44>: =
bne 0x50500 =
<compat_futex_noasync+248><br> 0x00050438 <+48>: =
mov r4, r0<br> =
0x0005043c <+52>: mov =
r8, r1<br> 0x00050440 <+56>: =
mov r5, r2<br> =
0x00050444 <+60>: bl =
0x108f4 <__sync_synchronize@plt><br> =
0x00050448 <+64>: ldr =
r3, [pc, #276] @ 0x50564 =
<compat_futex_noasync+348><br> 0x0005044c <+68>: =
ldr r6, [r9, r3]<br> =
0x00050450 <+72>: mov =
r0, r6<br> 0x00050454 <+76>: =
bl 0xf250 =
<__libc_mutex_lock@plt><br> 0x00050458 <+80>: =
subs r7, r0, #0<br> =
0x0005045c <+84>: bne =
0x504f4 <compat_futex_noasync+236><br> =
0x00050460 <+88>: cmp =
r8, #0<br> 0x00050464 <+92>: =
beq 0x504b4 =
<compat_futex_noasync+172><br> 0x00050468 <+96>: =
cmp r8, #1<br> =
0x0005046c <+100>: bne =
0x504a0 <compat_futex_noasync+152><br> =
0x00050470 <+104>: ldr =
r3, [pc, #240] @ 0x50568 =
<compat_futex_noasync+352><br> 0x00050474 =
<+108>: ldr r3, [r9, r3]<br> =
0x00050478 <+112>: mov =
r0, r3<br> 0x0005047c <+116>: =
str r3, [sp, #4]<br> =
0x00050480 <+120>: bl =
0x10f30 =
<__libc_cond_broadcast@plt><br> 0x00050484 =
<+124>: mov r0, r6<br> =
0x00050488 <+128>: bl =
0x117f4 =
<__libc_mutex_unlock@plt><br> 0x0005048c <+132>: =
subs r4, r0, #0<br> 0x00050490 =
<+136>: bne 0x504e4 =
<compat_futex_noasync+220><br> 0x00050494 =
<+140>: mov r0, r7<br> =
0x00050498 <+144>: add =
sp, sp, #12<br> 0x0005049c =
<+148>: pop {r4, r5, r6, r7, =
r8, r9, pc}<br> 0x000504a0 <+152>: bl =
0xebd8 <__errno@plt><br> =
0x000504a4 <+156>: mov =
r3, #22<br> 0x000504a8 <+160>: =
mvn r7, #0<br> =
0x000504ac <+164>: str =
r3, [r0]<br> 0x000504b0 =
<+168>: b 0x50484 =
<compat_futex_noasync+124><br> 0x000504b4 =
<+172>: ldr r3, [r4]<br> =
0x000504b8 <+176>: cmp =
r5, r3<br> 0x000504bc <+180>: =
bne 0x50484 =
<compat_futex_noasync+124><br>=3D> 0x000504c0 <+184>: =
ldr r3, [pc, #160] @ 0x50568 =
<compat_futex_noasync+352><br> 0x000504c4 =
<+188>: ldr r8, [r9, r3]<br> =
0x000504c8 <+192>: mov =
r1, r6<br> 0x000504cc <+196>: =
mov r0, r8<br> =
0x000504d0 <+200>: bl =
0x10ea0 <__libc_cond_wait@plt><br> =
0x000504d4 <+204>: ldr =
r3, [r4]<br> 0x000504d8 =
<+208>: cmp r3, r5<br> =
0x000504dc <+212>: beq =
0x504c8 <compat_futex_noasync+192><br> =
0x000504e0 <+216>: b =
0x50484 =
<compat_futex_noasync+124><br> 0x000504e4 =
<+220>: bl 0xebd8 =
<__errno@plt><br> 0x000504e8 <+224>: =
str r4, [r0]<br> =
0x000504ec <+228>: mvn =
r7, #0<br> 0x000504f0 <+232>: =
b 0x50494 =
<compat_futex_noasync+140><br> 0x000504f4 =
<+236>: bl 0xebd8 =
<__errno@plt><br> 0x000504f8 <+240>: =
str r7, [r0]<br> =
0x000504fc <+244>: b =
0x504ec =
<compat_futex_noasync+228><br> 0x00050500 =
<+248>: ldr r3, [pc, #100] =
@ 0x5056c <compat_futex_noasync+356><br> =
0x00050504 <+252>: ldr =
r2, [pc, #100] @ 0x50570 =
<compat_futex_noasync+360><br> 0x00050508 =
<+256>: ldr r0, [pc, #100] =
@ 0x50574 <compat_futex_noasync+364><br> =
0x0005050c <+260>: mov =
r1, #51 @ 0x33<br> 0x00050510 =
<+264>: add r3, pc, r3<br> =
0x00050514 <+268>: add =
r2, pc, r2<br> 0x00050518 =
<+272>: add r0, pc, r0<br> =
0x0005051c <+276>: bl =
0x10984 <__assert13@plt><br> =
0x00050520 <+280>: ldr =
r3, [pc, #80] @ 0x50578 =
<compat_futex_noasync+368><br> 0x00050524 =
<+284>: ldr r2, [pc, #80] =
@ 0x5057c <compat_futex_noasync+372><br> =
0x00050528 <+288>: ldr =
r0, [pc, #80] @ 0x50580 =
<compat_futex_noasync+376><br> 0x0005052c =
<+292>: mov r1, #50 @ 0x32<br> =
0x00050530 <+296>: add =
r3, pc, r3<br> 0x00050534 =
<+300>: add r2, pc, r2<br> =
0x00050538 <+304>: add =
r0, pc, r0<br> 0x0005053c =
<+308>: bl 0x10984 =
<__assert13@plt><br> 0x00050540 <+312>: =
ldr r3, [pc, #60] @ =
0x50584 <compat_futex_noasync+380><br> 0x00050544 =
<+316>: ldr r2, [pc, #60] =
@ 0x50588 <compat_futex_noasync+384><br> =
0x00050548 <+320>: ldr =
r0, [pc, #60] @ 0x5058c =
<compat_futex_noasync+388><br> 0x0005054c =
<+324>: mov r1, #49 @ 0x31<br> =
0x00050550 <+328>: add =
r3, pc, r3<br> 0x00050554 =
<+332>: add r2, pc, r2<br> =
0x00050558 <+336>: add =
r0, pc, r0<br> 0x0005055c =
<+340>: bl 0x10984 =
<__assert13@plt><br> 0x00050560 <+344>: =
muleq r4, r4, r2<br> 0x00050564 =
<+348>: strdeq r0, [r0], -r12<br> =
0x00050568 <+352>: ldrdeq r0, [r0], =
-r8<br> 0x0005056c <+356>: andeq =
r8, r2, r12, ror r4<br> 0x00050570 <+360>: =
andeq r4, r3, r8, lsl #19<br> =
0x00050574 <+364>: andeq r8, =
r2, r4, lsl r4<br> 0x00050578 <+368>: =
andeq r8, r2, r4, asr r4<br> =
0x0005057c <+372>: andeq r4, =
r3, r8, ror #18<br> 0x00050580 <+376>: =
strdeq r8, [r2], -r4<br> 0x00050584 =
<+380>: ldrdeq r8, [r2], -r0<br> =
0x00050588 <+384>: andeq r4, =
r3, r8, asr #18<br> 0x0005058c <+388>: =
ldrdeq r8, [r2], -r4<br>End of assembler =
dump.<br><br><br><blockquote =
type=3D"cite">How-To-Repeat:<br></blockquote>not quite sure, evbearmv5 =
specific?<br><br><blockquote =
type=3D"cite">Fix:<br></blockquote>n/a<br></div></div></blockquote></div><=
br></div></body></html>=
--Apple-Mail=_F2896C6F-CE9F-4AF4-A9F7-20BEC905BDEA--
--Apple-Mail=_8FD8957E-16BF-4232-850A-E68F2B9AC06E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCZ5llqwAKCRBxESqxbLM7
OimCAJ0X4t9TDg0u09bAGBRxC3cObahR7wCeKGMZnbUqkhKByCcZjP/J+J49JyA=
=S4x8
-----END PGP SIGNATURE-----
--Apple-Mail=_8FD8957E-16BF-4232-850A-E68F2B9AC06E--
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/59035: new named(8) crashes at startup on evbarmv5
Date: Wed, 29 Jan 2025 13:08:35 +0100
I ran it from gdb with -f and get this backtrace:
(gdb) bt -full
#0 _cds_wfcq_enqueue (new_tail=0xbb2952a8, tail=0x100, head=...)
at /work/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/static/wfcqueue.h:217
No locals.
#1 _call_rcu (crdp=0x100, func=0xbbd40208 <dispatch_destroy_rcu>, head=0xbb2952a8)
at /work/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-call-rcu-impl.h:705
No locals.
#2 urcu_memb_call_rcu (head=0xbb2952a8, func=0xbbd40208 <dispatch_destroy_rcu>)
at /work/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-call-rcu-impl.h:732
crdp = 0x100
#3 0xbbd42168 in dispentry_destroy (resp=0xbb1009a8)
at /work/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:445
disp = 0x0
disp = <optimized out>
#4 dns_dispentry_unref (ptr=0xbb1009a8) at /work/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:453
No locals.
#5 0xbbd437cc in send_done (handle=<optimized out>, result=ISC_R_SUCCESS, cbarg=<optimized out>)
at /work/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:2092
resp = 0x0
disp = <optimized out>
#6 0xbbbe4434 in isc___nm_connectcb (arg=0xbb27ec48)
at /work/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/netmgr.c:1841
uvreq = 0xbb27ec48
#7 isc__nm_sendcb (sock=0xba434e08, uvreq=0xbb27ec48, eresult=ISC_R_SUCCESS, async=<optimized out>)
at /work/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/netmgr.c:1910
No locals.
#8 0xbbc06a28 in uv__udp_run_completed (handle=0xba434fc0) at /work/src/external/mit/libuv/lib/../dist/src/unix/udp.c:157
req = 0xbb27ecc8
q = 0xbb27ecf0
__func__ = "uv__udp_run_completed"
#9 0xbbc0de48 in uv__run_pending (loop=loop@entry=0xbb2c2518) at /work/src/external/mit/libuv/lib/../dist/src/unix/core.c:810
q = <optimized out>
pq = {0xba435384, 0xba435704}
w = <optimized out>
#10 0xbbc0e2b4 in uv_run (loop=0xbb2c2518, mode=UV_RUN_DEFAULT) at /work/src/external/mit/libuv/lib/../dist/src/unix/core.c:411
timeout = <optimized out>
r = <optimized out>
can_sleep = <optimized out>
#11 0xbbbf6e94 in loop_thread (arg=0xbb2c2508) at /work/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/loop.c:329
loop = 0xbb2c2508
loopmgr = 0xbb2940c8
helper = 0xbb2c2a08
crdp=0x100 and tail=0x100 look like strange pointers.
Martin
From: Tobias Nygren <tnn@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59035: new named(8) crashes at startup on evbarmv5
Date: Fri, 14 Feb 2025 21:34:33 +0100
Reproducable on aarch64 as well. "named -g" core dumps immediately[1].
On aarch64 I found that I can paper over the crash with this patch.
--- external/lgpl2/userspace-rcu/lib/liburcu-memb/Makefile 17 Jan 2025 16:07:27 -0000 1.1
+++ external/lgpl2/userspace-rcu/lib/liburcu-memb/Makefile 14 Feb 2025 20:31:37 -0000
@@ -8,4 +8,6 @@ CPPFLAGS+=-DRCU_MEMBARRIER
SRCS+= urcu.c urcu-pointer.c compat_arch.c compat_futex.c
+COPTS.urcu.c+=-O0
+
.include <bsd.lib.mk>
[1]
Thread 7 "isc-loop-0005" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 24143 of process 3105]
_cds_wfcq_enqueue (new_tail=0xf011f2ca6130, tail=0x1, head=...)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/static/wfcqueue.h:217
217 return ___cds_wfcq_append(head, tail, new_tail, new_tail);
(gdb) bt
#0 _cds_wfcq_enqueue (new_tail=0xf011f2ca6130, tail=0x1, head=...)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/static/wfcqueue.h:217
#1 _call_rcu (head=head@entry=0xf011f2ca6130, func=<optimized out>, crdp=0x1)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-call-rcu-impl.h:705
#2 0x000000000f37f628 in urcu_memb_call_rcu (head=head@entry=0xf011f2ca6130, func=func@entry=0xf011f85d7960 <dispentry_destroy_rcu>)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-call-rcu-impl.h:732
#3 0x0000f011f85d981c in dispentry_destroy (resp=0xf011f2ca6010) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:447
#4 dns_dispentry_unref (ptr=0xf011f2ca6010) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:453
#5 0x0000f011f85da4c0 in udp_recv (handle=0xf011f2e0b010, eresult=ISC_R_SUCCESS, region=0xf011f37cdb70, arg=<optimized out>)
at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:628
#6 0x0000f011f84438f0 in isc.nm_readcb () from /usr/lib/libisc.so.23
#7 0x0000f011f842d8bc in isc.nm_udp_read_cb () from /usr/lib/libisc.so.23
#8 0x0000f011f8462b80 in ?? () from /usr/lib/libisc.so.23
#9 0x0000f011f846203c in uv.io_poll () from /usr/lib/libisc.so.23
#10 0x0000f011f846a2a0 in uv_run () from /usr/lib/libisc.so.23
#11 0x0000f011f8454b0c in ?? () from /usr/lib/libisc.so.23
#12 0x0000f011f8459eec in ?? () from /usr/lib/libisc.so.23
#13 0x0000f011f824dad4 in ?? () from /usr/lib/libpthread.so.1
#14 0x0000f011f75e26a0 in __mknod50 () from /usr/lib/libc.so.12
From: Tobias Nygren <tnn@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59035: new named(8) crashes at startup on evbarmv5
Date: Fri, 14 Feb 2025 22:00:12 +0100
There is a GCC warning about an out of bounds write which only appears at -O0.
Maybe related.
In file included from /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/uatomic/aarch64.h:31,
from /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/uatomic.h:85,
from /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/static/wfcqueue.h:21,
from /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/wfcqueue.h:177,
from /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu.c:30:
In function '_uatomic_add_return',
inlined from 'wait_defer' at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-defer-impl.h:169:2:
/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/uatomic/generic.h:301:24: error: '__sync_add_and_fetch_8' writing 8 bytes into a region of size 4 overflows the destination [-Werror=stringop-overflow=]
301 | return __sync_add_and_fetch_8((uint64_t *) addr, val);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu.c:558:
/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-defer-impl.h: In function 'wait_defer':
/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-defer-impl.h:109:16: note: destination object 'defer_thread_futex' of size 4
109 | static int32_t defer_thread_futex;
| ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
From: Tobias Nygren <tnn@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: Martin Husemann <martin@NetBSD.org>
Subject: Re: bin/59035: new named(8) crashes at startup on evbarmv5
Date: Sun, 16 Feb 2025 00:42:31 +0100
Something might be going awry with liburcu's ELF constructors
when it is linked into named as a static library. The
thread_call_rcu_data pointer which is supposed to be inited by the
constructor contains apparent garbage at startup.
The easiest workaround seems to be to remove the constructor.
I think this is safe because rcu_register_thread calls rcu_init
regardless ...
Martin, does this help on earmv5?
(May be need to clean obj/external/{lgpl2,mpl} manually)
--- external/lgpl2/userspace-rcu/dist/src/urcu.c 17 Jan 2025 16:00:50 -0000 1.1.1.1
+++ external/lgpl2/userspace-rcu/dist/src/urcu.c 15 Feb 2025 23:38:07 -0000
@@ -83,7 +83,7 @@ static int urcu_memb_has_sys_membarrier_
int urcu_memb_has_sys_membarrier = 0;
#endif
-void __attribute__((constructor)) rcu_init(void);
+void rcu_init(void);
#endif
#if defined(RCU_MB)
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2025
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home