NetBSD Problem Report #59652

From www@netbsd.org  Sat Sep 13 20:02:56 2025
Return-Path: <www@netbsd.org>
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)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 25ED81A923D
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 13 Sep 2025 20:02:56 +0000 (UTC)
Message-Id: <20250913200254.C4EE21A923E@mollari.NetBSD.org>
Date: Sat, 13 Sep 2025 20:02:54 +0000 (UTC)
From: brandon@burn.net
Reply-To: brandon@burn.net
To: gnats-bugs@NetBSD.org
Subject: DNS utilities core dump in -current
X-Send-Pr-Version: www-1.0

>Number:         59652
>Category:       toolchain
>Synopsis:       DNS utilities core dump in -current
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 13 20:05:00 +0000 2025
>Closed-Date:    
>Last-Modified:  Wed Oct 01 18:30:01 +0000 2025
>Originator:     Brandon Applegate
>Release:        11.0-BETA Aug 27 2025
>Organization:
>Environment:
NetBSD c3700.retronet.burn.net 11.99.1 NetBSD 11.99.1 (GENERIC) #0: Sun Aug  3 08:22:49 UTC 2025  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/hppa/compile/GENERIC hppa
>Description:
Example:

c3700$ dig burn.net
assertion "!(urcu_memb_reader).registered" failed: file "/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu.c", line 486, function "urcu_memb_register_thread"
[1]   Abort trap (core dumped) dig burn.net

And from a slightly later build (Aug. 27):

[vom@c3700 ~]$ uname -a
NetBSD c3700.retronet.burn.net 11.0_BETA NetBSD 11.0_BETA (GENERIC) #0: Wed Aug 27 12:56:40 UTC 2025  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/hppa/compile/GENERIC hppa

[vom@c3700 ~]$ dig arin.net soa
assertion "!(urcu_mb_reader).registered" failed: file "/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-mb/../../dist/src/urcu.c", line 486, function "urcu_mb_register_thread"
Abort trap (core dumped)

I personally hit this issue on hppa, but reading the mailing list thread it seems other ports may be affected as well.

Please also see:

https://mail-index.netbsd.org/netbsd-users/2025/08/03/msg032919.html

For some discussion on this...
>How-To-Repeat:
Try to ISC BIND utilities (ex: dig, delv) on a -current machine.
>Fix:
Unknown

>Release-Note:

>Audit-Trail:
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Cc: 
Subject: Re: lib/59652: DNS utilities core dump in -current
Date: Sun, 21 Sep 2025 08:26:06 +0100

 I've analysed this and it's a compiler/linker bug.

 A cut down program of

 $ cat urcu.c
 typedef struct __pthread_st *pthread_t;
 pthread_t __libc_thr_self(void);

 struct cds_list_head {
   struct cds_list_head *next, *prev;
 };

 struct urcu_reader {
   unsigned long ctr;

   struct cds_list_head node __attribute__((aligned(64)));

   unsigned int registered:1;
 };

 __thread struct urcu_reader urcu_mb_reader;

 int
 main(void)
 {
          int ret =3D urcu_mb_reader.registered;

          return ret;
 }
 $


 The compiler generates the following code

 00000000 <main>:
     0:   03 60 08 bc     mfctl tr3,ret0
     4:   2b 80 00 00     addil L%0,ret0,r1
                          4: R_PARISC_TPREL21L    urcu_mb_reader
     8:   34 3c 00 00     ldo 0(r1),ret0
                          8: R_PARISC_TPREL14R    urcu_mb_reader
     c:   37 9c 00 90     ldo 48(ret0),ret0
    10:   0f 80 10 9c     ldw 0(ret0),ret0
    14:   e8 40 c0 00     bv r0(rp)
    18:   d3 9c 18 1f     extrw,u ret0,0,1,ret0


 which the linker resolves to a load from 0x40 + 0x4c (0x8c) relative to=20
 the TLS area

 000107b4 <main>:
     107b4:       03 60 08 bc     mfctl tr3,ret0
     107b8:       2b 80 00 00     addil L%0,ret0,r1
     107bc:       34 3c 00 80     ldo 40(r1),ret0
     107c0:       37 9c 00 90     ldo 48(ret0),ret0
     107c4:       0f 80 10 9c     ldw 0(ret0),ret0
     107c8:       e8 40 c0 00     bv r0(rp)
     107cc:       d3 9c 18 1f     extrw,u ret0,0,1,ret0


 which is outside the 0x80 bytes allocated.
 $ readelf -S urcu  | grep tbss
    [14] .tbss             NOBITS          00011000 001000 000080 00 WAT=20
 0   0 64
 $

Responsible-Changed-From-To: lib-bug-people->toolchain
Responsible-Changed-By: skrll@NetBSD.org
Responsible-Changed-When: Sun, 21 Sep 2025 08:01:49 +0000
Responsible-Changed-Why:
It's a compiler/linker bug.


State-Changed-From-To: open->analyzed
State-Changed-By: skrll@NetBSD.org
State-Changed-When: Sun, 21 Sep 2025 08:01:49 +0000
State-Changed-Why:
I've analysed the problem, obvs.


Responsible-Changed-From-To: toolchain->toolchain-manager
Responsible-Changed-By: skrll@NetBSD.org
Responsible-Changed-When: Sun, 21 Sep 2025 08:03:26 +0000
Responsible-Changed-Why:
it's toolchain-manager (and not toolchain)


From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org, brandon@burn.net
Cc: 
Subject: Re: lib/59652: DNS utilities core dump in -current
Date: Mon, 29 Sep 2025 18:27:01 +0100

 More analysis shows me it's a ld.elf_so bug that means the data isn't=20
 aligned correctly relative to the struct tcb_tls for__HAVE_TLS_VARIANT_I

 I didn't check __HAVE_TLS_VARIANT_II yet.

 Here's a little test program that fails.

 #include <inttypes.h>
 #include <assert.h>

 #define ALIGNMENT       64

 #define MAGIC1  0xaa55aa55aa55aa55
 #define MAGIC2  0xc0ffeeeeeeeeeeee
 #define MAGIC3  0xff00ff00ff00ff00

 __thread
 struct {
          uint64_t magic1;
          uint64_t magic2 __attribute__((aligned(ALIGNMENT)));
          uint64_t magic3;
 } tls_data =3D {
          .magic1 =3D MAGIC1,
          .magic2 =3D MAGIC2,
          .magic3 =3D MAGIC3,
 };

 int
 main()
 {
          assert(tls_data.magic1 =3D=3D MAGIC1);
          assert(tls_data.magic2 =3D=3D MAGIC2);
          assert(tls_data.magic3 =3D=3D MAGIC3);
 }


From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org, brandon@burn.net
Cc: 
Subject: Re: lib/59652: DNS utilities core dump in -current
Date: Tue, 30 Sep 2025 06:56:46 +0100

 Test program passes on x86_64 which is __HAVE_TLS_VARIANT_II.

From: "Nick Hudson" <skrll@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59652 CVS commit: src/libexec/ld.elf_so
Date: Tue, 30 Sep 2025 06:12:54 +0000

 Module Name:	src
 Committed By:	skrll
 Date:		Tue Sep 30 06:12:53 UTC 2025

 Modified Files:
 	src/libexec/ld.elf_so: tls.c

 Log Message:
 Add some more debug in light of PR/59652: DNS utilities core dump...


 To generate a diff of this commit:
 cvs rdiff -u -r1.24 -r1.25 src/libexec/ld.elf_so/tls.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: =?UTF-8?Q?J=C3=B6rg_Sonnenberger?= <joerg@bec.de>
To: gnats-bugs@netbsd.org, toolchain-manager@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, brandon@burn.net
Cc: 
Subject: Re: lib/59652: DNS utilities core dump in -current
Date: Wed, 1 Oct 2025 00:10:19 +0200

 On 9/29/25 7:30 PM, Nick Hudson via gnats wrote:
 > The following reply was made to PR toolchain/59652; it has been noted by GNATS.
 > 
 > From: Nick Hudson <nick.hudson@gmx.co.uk>
 > To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
 >   netbsd-bugs@netbsd.org, brandon@burn.net
 > Cc:
 > Subject: Re: lib/59652: DNS utilities core dump in -current
 > Date: Mon, 29 Sep 2025 18:27:01 +0100
 > 
 >   More analysis shows me it's a ld.elf_so bug that means the data isn't=20
 >   aligned correctly relative to the struct tcb_tls for__HAVE_TLS_VARIANT_I

 We don't support alignment stricter than the malloc default for TLS. 
 Primarily because the ld.elf_so malloc has no support for it, but also 
 in case of static TLS because there would be no way to increase 
 alignment after the initial TCB has been created.

 Joerg

From: Brandon Applegate <brandon@burn.net>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/59652: DNS utilities core dump in -current
Date: Wed, 1 Oct 2025 14:25:57 -0400

 You folks might already be aware of this - but there seems to be a =
 thread active on the bind-users ML right now regarding this issue:

 https://lists.isc.org/pipermail/bind-users/2025-October/110181.html

 --
 Brandon Applegate - CCIE 10273
 PGP Key fingerprint:
 A269 60C3 7335 29E3 0DDA 0197 1834 C1F9 A1B2 559A
 "For thousands of years men dreamed of pacts with demons.
 Only now are such things possible."

>Unformatted:

Home	PR Database Search