NetBSD Problem Report #60472

From tron@zhadum.org.uk  Mon Jul 20 18:33:03 2026
Return-Path: <tron@zhadum.org.uk>
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 "YR2" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 332AC1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 20 Jul 2026 18:33:03 +0000 (UTC)
Message-Id: <20260720183259.6CD7EF8EDE@lyssa.zhadum.org.uk>
Date: Mon, 20 Jul 2026 19:32:59 +0100 (BST)
From: tron@zhadum.org.uk
Reply-To: tron@zhadum.org.uk
To: gnats-bugs@NetBSD.org
Subject: ld.elf_so(1) changes cause a segmentation fault in dlopen(3)
X-Send-Pr-Version: 3.95
X-From4GNATS: "tron@zhadum.org.uk via gnats" <gnats-admin@NetBSD.org>

>Number:         60472
>Category:       bin
>Synopsis:       ld.elf_so(1) changes cause a segmentation fault in dlopen(3)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    riastradh
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 20 18:35:00 +0000 2026
>Closed-Date:    Tue Jul 21 06:53:47 +0000 2026
>Last-Modified:  Wed Jul 22 05:25:04 +0000 2026
>Originator:     tron@zhadum.org.uk
>Release:        NetBSD 11.99.7 2026-07-20 06:00 UTC sources
>Organization:
Matthias Scheler                                 https://zhadum.org.uk/
>Environment:
System: NetBSD lyssa.zhadum.org.uk 11.99.7 NetBSD 11.99.7 (GENERIC) #0: Mon Jul 20 14:06:12 BST 2026 tron@lyssa.zhadum.org.uk:/export/scratch/tron/sys/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
After upgrading my NetBSD-amd64 system from NetBSD-current 2026-07-13 to
2026-07-20 I can no longer build the "textproc/xmlto" package from
"pkgsrc". There might be more problems but this is the first one that
I've noticed.

This caused by a segmentation fault in the "/usr/pkg/bin/xsltproc" utility.
A core dump suggests that it crashes in dlopen(3).

After downgrading ld.elf_so(1) to 2026-07-13 sources the "xsltproc" utility
works fien again.

>How-To-Repeat:
cd pkgsrc/textproc/xmlto
make

>Fix:
None known

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Mon, 20 Jul 2026 18:45:17 +0000
State-Changed-Why:
Can you please provide the stack trace from the core dump?


Responsible-Changed-From-To: bin-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Mon, 20 Jul 2026 18:47:12 +0000
Responsible-Changed-Why:
assign this bull the liability for the china shop


From: Matthias Scheler <tron@zhadum.org.uk>
To: gnats-bugs@netbsd.org
Cc: riastradh@NetBSD.org
Subject: Re: bin/60472 (ld.elf_so(1) changes cause a segmentation fault in
 dlopen(3))
Date: Mon, 20 Jul 2026 19:57:59 +0100

 On Mon, Jul 20, 2026 at 06:45:18PM +0000, riastradh@NetBSD.org wrote:
 > Synopsis: ld.elf_so(1) changes cause a segmentation fault in dlopen(3)
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: riastradh@NetBSD.org
 > State-Changed-When: Mon, 20 Jul 2026 18:45:17 +0000
 > State-Changed-Why:
 > Can you please provide the stack trace from the core dump?

 That would require breaking my system again. And it is currently busy
 rebuilding packages with hundreds more to go.

 Did you try my reproduction step? It works a hundred percent reliable for me.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Taylor R Campbell <riastradh@NetBSD.org>
To: tron@zhadum.org.uk
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org, ryoon@NetBSD.org
Subject: Re: bin/60472: ld.elf_so(1) changes cause a segmentation fault in dlopen(3)
Date: Mon, 20 Jul 2026 19:05:31 +0000

 > Date: Mon, 20 Jul 2026 18:45:18 +0000 (UTC)
 > From: riastradh@NetBSD.org
 >=20
 > Can you please provide the stack trace from the core dump?

 In particular, is it the same (for the part inside ld.elf_so) as this
 stack trace that ryoon@ posted?

 Core was generated by `firefox-bin'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x00007f7ff7ac580a in _rtld_load_library (
     name=3Dname@entry=3D0x7f7fff6e3940 "/usr/pkg/lib/dri/tls/swrast_dri.so",
     refobj=3Drefobj@entry=3D0x74cccaeb3000, flags=3Dflags@entry=3D9,
     mask=3Dmask@entry=3D0x7f7fff6e38b0) at /usr/src/libexec/ld.elf_so/searc=
 h.c:197
 197             assert(obj->refcount > 0);
 [Current thread is 1 (process 3675)]
 (gdb) bt
 #0  0x00007f7ff7ac580a in _rtld_load_library (
     name=3Dname@entry=3D0x7f7fff6e3940 "/usr/pkg/lib/dri/tls/swrast_dri.so",
     refobj=3Drefobj@entry=3D0x74cccaeb3000, flags=3Dflags@entry=3D9,
     mask=3Dmask@entry=3D0x7f7fff6e38b0) at /usr/src/libexec/ld.elf_so/searc=
 h.c:197
 #1  0x00007f7ff7ac2c4e in dlopen (
     name=3D0x7f7fff6e3940 "/usr/pkg/lib/dri/tls/swrast_dri.so", mode=3D258)
     at /usr/src/libexec/ld.elf_so/rtld.c:1696
 #2  0x000074ccb9d75b35 in loader_open_driver_lib () from /usr/pkg/lib/libGL=
 .so

 If so, it should be fixed by this commit:

 https://mail-index.netbsd.org/source-changes/2026/07/20/msg163255.html


 As a workaround, you can also comment out the line

 src/libexec/ld.elf_so:CPPFLAGS+=3D	-DDEBUG

 I enabled it in current the other day so we would shake out all the
 bitrot in ld.elf_so assertions over the years to make them useful
 again as a diagnostic measure, especially for chasing hard-to-find
 race conditions like PR lib/59751: dlclose is not MT-safe depending on
 the libraries unloaded <https://gnats.NetBSD.org/59751>.

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Matthias Scheler <tron@zhadum.org.uk>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/60472 (ld.elf_so(1) changes cause a segmentation fault in
	dlopen(3))
Date: Mon, 20 Jul 2026 19:17:28 +0000

 > Date: Mon, 20 Jul 2026 19:57:59 +0100
 > From: Matthias Scheler <tron@zhadum.org.uk>
 >=20
 > On Mon, Jul 20, 2026 at 06:45:18PM +0000, riastradh@NetBSD.org wrote:
 > > Can you please provide the stack trace from the core dump?
 >=20
 > That would require breaking my system again. And it is currently busy
 > rebuilding packages with hundreds more to go.

 If you still have the core dump and
 /usr/libdata/debug/usr/lib/ld.elf_so.debug, that should be enough to
 get a stack trace.  (If all you have is the core dump, you can just
 rebuild ld.elf_so from the same source date as before and the
 ld.elf_so.debug should work.)

 > Did you try my reproduction step? It works a hundred percent reliable for=
  me.

 No, haven't tried yet, sorry, was hoping the stack trace was still
 available.  Working on fixing several things at once here, not just
 ld.elf_so!

From: Matthias Scheler <tron@zhadum.org.uk>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/60472 (ld.elf_so(1) changes cause a segmentation fault in
 dlopen(3))
Date: Mon, 20 Jul 2026 21:02:16 +0100

 On Mon, Jul 20, 2026 at 07:17:28PM +0000, Taylor R Campbell wrote:
 > > That would require breaking my system again. And it is currently busy
 > > rebuilding packages with hundreds more to go.
 > 
 > If you still have the core dump and
 > /usr/libdata/debug/usr/lib/ld.elf_so.debug, that should be enough to
 > get a stack trace.  (If all you have is the core dump, you can just
 > rebuild ld.elf_so from the same source date as before and the
 > ld.elf_so.debug should work.)

 The core dump was in the work directory of the "textproc/libxslt" package
 which got cleaned in the meantime unfortunately.

 Is there a way e.g. by setting an environment variable to use an
 alternative "ld.elf_so" to execute a binary?

 In worst case I can try to reproduce the problem tomorrow.

 > > Did you try my reproduction step? It works a hundred percent reliable for me.
 > 
 > No, haven't tried yet, sorry, was hoping the stack trace was still
 > available.  Working on fixing several things at once here, not just
 > ld.elf_so!

 Thank you very much for your efforts.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Matthias Scheler <tron@zhadum.org.uk>
Cc: gnats-bugs@NetBSD.org, gnats-bugs@NetBSD.org
Subject: Re: bin/60472 (ld.elf_so(1) changes cause a segmentation fault in
	dlopen(3))
Date: Mon, 20 Jul 2026 20:40:49 +0000

 > Date: Mon, 20 Jul 2026 21:02:16 +0100
 > From: Matthias Scheler <tron@zhadum.org.uk>
 > 
 > On Mon, Jul 20, 2026 at 07:17:28PM +0000, Taylor R Campbell wrote:
 > > If you still have the core dump and
 > > /usr/libdata/debug/usr/lib/ld.elf_so.debug, that should be enough to
 > > get a stack trace.  (If all you have is the core dump, you can just
 > > rebuild ld.elf_so from the same source date as before and the
 > > ld.elf_so.debug should work.)
 > 
 > The core dump was in the work directory of the "textproc/libxslt" package
 > which got cleaned in the meantime unfortunately.

 OK, no worries.

 > Is there a way e.g. by setting an environment variable to use an
 > alternative "ld.elf_so" to execute a binary?

 No, unfortunately not: it is rigidly fixed to execute the path it
 finds in the PT_INTERP program header.

 As an alternative (which I've sometimes done in the past while hacking
 ld.elf_so), you could:

 1. ^Z in any terminals where you're running builds
 2. install the new ld.elf_so into /libexec/ld.elf_so.new
 3. /rescue/ln /libexec/ld.elf_so /libexec/ld.elf_so.old
 4. /rescue/ln /libexec/ld.elf_so.new /libexec/ld.elf_so.tmp
 5. /rescue/mv -f /libexec/ld.elf_so.tmp /libexec/ld.elf_so
 6. [test the reproducer]
 7. /rescue/ln /libexec/ld.elf_so.old /libexec/ld.elf_so.tmp
 8. /rescue/mv -f /libexec/ld.elf_so.tmp /libexec/ld.elf_so
 9. fg in the terminals where you're running builds

 (In this case, the use of /rescue may not be necessary, if the bug is
 what I'm guessing it is and doesn't actually affect /bin/ln or /bin/mv
 or anything like that, but /rescue has saved me in the past when doing
 shenanigans like this.)

 You could also take a snapshot of / just before messing with it and
 mount it so you can recover with /rescue/pax or /rescue/tar if
 anything goes wrong.  If you're using ffs:

 1. ^Z builds
 2. mkdir /.snap /.snap/20260720
 3. fssconfig fss0 / /.snap/20260720.snap
 4. mount /dev/fss0 /.snap/20260720
 5. [screw up /libexec and test the reproducer]
 6. cd /.snap/20260720/libexec && /rescue/pax -rw -pe . /libexec/.
 7. umount /.snap/20260720
 8. fssconfig -u fss0
 9. rm /.snap/20260720.snap
 10. fg builds

 If you're using zfs, probably something like `zfs snap -r
 rpool/ROOT@20260720' and then either `zfs rollback' or fish it out of
 /.zfs/snapshot/20260720 instead.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60472 CVS commit: src/libexec/ld.elf_so
Date: Tue, 21 Jul 2026 04:05:06 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Tue Jul 21 04:05:06 UTC 2026

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

 Log Message:
 ld.elf_so: Fix one more mistake in handling _rtld_load_object.

 This can return NULL (meaning object not found or something went wrong
 with the object) or OBJ_ERR (meaning the object has DF_1_NOOPEN set or
 the caller passed RTLD_NOLOAD to dlopen() and the object was not
 already loaded) or a valid object.

 I reviewed all paths out of _rtld_load_object to make sure they
 gracefully handle all three cases (NULL, OBJ_ERR, valid object), and
 this assertion was the only path that didn't.

 Fixes buggy assertion added for:

 PR lib/59751: dlclose is not MT-safe depending on the libraries
 unloaded

 May fix:

 PR bin/60472: ld.elf_so(1) changes cause a segmentation fault in
 dlopen(3)


 To generate a diff of this commit:
 cvs rdiff -u -r1.29 -r1.30 src/libexec/ld.elf_so/search.c

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

State-Changed-From-To: feedback->closed
State-Changed-By: tron@NetBSD.org
State-Changed-When: Tue, 21 Jul 2026 06:53:47 +0000
State-Changed-Why:
The problem has been fixed in the latest version of ld.elf_so(1).


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60472 CVS commit: [netbsd-11] src/libexec/ld.elf_so
Date: Wed, 22 Jul 2026 05:22:33 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Jul 22 05:22:32 UTC 2026

 Modified Files:
 	src/libexec/ld.elf_so [netbsd-11]: search.c tls.c xmalloc.c

 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #393):

 	libexec/ld.elf_so/search.c: revision 1.30
 	libexec/ld.elf_so/xmalloc.c: revision 1.28
 	libexec/ld.elf_so/tls.c: revision 1.30
 	libexec/ld.elf_so/tls.c: revision 1.31
 	libexec/ld.elf_so/search.c: revision 1.29

 ld.elf_so: Fix assertion: obj may be NULL _or_ OBJ_ERR (-1) here
 NULL means the object wasn't found and we should keep searching;
 OBJ_ERR means the object was found but loading it failed and we
 should stop.  Only if the object is _neither_ NULL _nor_ OBJ_ERR is
 it expected to be an object with positive refcount.

 Followup for
 PR lib/59751: dlclose is not MT-safe depending on the libraries
 unloaded

 ld.elf_so: Fix static TLS alignment on variant II platforms.

 Only affects obscure architectures like x86, though.
 Sprinkle assertions to make sure this breaks in other ways on other
 architectures too, like variant I, or variant II with _lwp_gettcb().

 Fair's fair, right?

 XXX We should consider verifying that every Elf_Phdr::p_align is
 reasonable (i.e., is a power of two, or is zero but only if p_memsz
 is also zero), and that p_filesz <= p_memsz, in headers.c for the
 main object and in map_object.c for other objects.

 PR bin/60469: bin/60469: assertion "ALIGNED_P(q, obj->tlsalign)"
 failed: file "/usr/src/libexec/ld.elf_so/tls.c", line 333

 ld.elf_so: Mark new variables __debugused, not __diagused.

 They are used in ld.elf_so builds with DEBUG, not with DIAGNOSTIC!

 PR bin/60469: bin/60469: assertion "ALIGNED_P(q, obj->tlsalign)"
 failed: file "/usr/src/libexec/ld.elf_so/tls.c", line 333

 ld.elf_so: Fix one more mistake in handling _rtld_load_object.

 This can return NULL (meaning object not found or something went wrong
 with the object) or OBJ_ERR (meaning the object has DF_1_NOOPEN set or
 the caller passed RTLD_NOLOAD to dlopen() and the object was not
 already loaded) or a valid object.

 I reviewed all paths out of _rtld_load_object to make sure they
 gracefully handle all three cases (NULL, OBJ_ERR, valid object), and
 this assertion was the only path that didn't.

 Fixes buggy assertion added for:
 PR lib/59751: dlclose is not MT-safe depending on the libraries
 unloaded

 May fix:
 PR bin/60472: ld.elf_so(1) changes cause a segmentation fault in
 dlopen(3)


 To generate a diff of this commit:
 cvs rdiff -u -r1.27.10.1 -r1.27.10.2 src/libexec/ld.elf_so/search.c
 cvs rdiff -u -r1.23.2.2 -r1.23.2.3 src/libexec/ld.elf_so/tls.c
 cvs rdiff -u -r1.12.44.3 -r1.12.44.4 src/libexec/ld.elf_so/xmalloc.c

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

>Unformatted:

Home	PR Database Search