NetBSD Problem Report #60150
From tsutsui@ceres.dti.ne.jp Tue Mar 31 16:59:43 2026
Return-Path: <tsutsui@ceres.dti.ne.jp>
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 "R12" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 1BE411A9239
for <gnats-bugs@gnats.NetBSD.org>; Tue, 31 Mar 2026 16:59:43 +0000 (UTC)
Message-Id: <202603311659.62VGxblY000091@ceres.dti.ne.jp>
Date: Wed, 1 Apr 2026 01:59:37 +0900 (JST)
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Reply-To: tsutsui@ceres.dti.ne.jp
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: named(8) crashes at startup on NetBSD/i386 11.0_RC2
X-Send-Pr-Version: 3.95
X-From4GNATS: "Izumi Tsutsui via gnats" <gnats-admin@NetBSD.org>
>Number: 60150
>Category: bin
>Synopsis: named(8) crashes at startup on NetBSD/i386 11.0_RC2
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: bin-bug-people
>State: pending-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Mar 31 17:00:00 +0000 2026
>Closed-Date:
>Last-Modified: Wed May 06 16:55:00 +0000 2026
>Originator: Izumi Tsutsui
>Release: NetBSD 11.0_RC2
>Organization:
>Environment:
System: NetBSD mirage 11.0_RC2 NetBSD 11.0_RC2 (GENERIC) #0: Wed Mar 4 21:02:00 UTC 2026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
After upgrading my LAN DNS server machine from NetBSD/i386 10.1 to 11.0_RC2,
named(8) crashes right after startup.
The configuration itself appears to be valid:
- "named-checkconf /etc/named.conf" succeeds.
- zone files load successfully.
- "named -g -c /etc/named.conf" reaches "all zones loaded" and "running".
However, immediately after that, named aborts with an assertion failure in
liburcu:
---
assertion "!is_removal_owner(node)" failed: file "/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-cds/../../dist/src/rculfhash.c", line 1097, function "_cds_lfht_add"
Abort (core dumped)
---
Also, "named-checkconf -z /etc/named.conf" aborts instead of reporting a
configuration/zone error. Without "-z", named-checkconf succeeds.
This seems related to the known recent named/liburcu startup crash reports,
for example PR bin/59035 and PR/59571.
https://gnats.netbsd.org/59035
https://gnats.netbsd.org/59571
>How-To-Repeat:
1. Use NetBSD/i386 11.0_RC2.
2. Configure a normal authoritative/caching named setup with local zones.
3. Run:
named-checkconf /etc/named.conf
named-checkconf -z /etc/named.conf
named -g -c /etc/named.conf
Observed results:
- named-checkconf without "-z" succeeds.
- named-checkconf -z aborts.
- named -g loads all zones, prints "running", then aborts.
Example output from "named -g -c /etc/named.conf":
---
01-Apr-2026 01:54:25.024 starting BIND 9.20.11 (Stable Release) <id:c6b2e31>
01-Apr-2026 01:54:25.024 running on NetBSD i386 11.0_RC2 NetBSD 11.0_RC2 (GENERIC) #0: Wed Mar 4 21:02:00 UTC 2026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
01-Apr-2026 01:54:25.024 built with '--enable-querytrace' '--enable-fixed-rrset'
01-Apr-2026 01:54:25.024 running as: named -g -c /etc/named.conf
01-Apr-2026 01:54:25.024 compiled by GCC 12.5.0
01-Apr-2026 01:54:25.024 compiled with OpenSSL version: OpenSSL 3.5.1 1 Jul 2025
01-Apr-2026 01:54:25.024 linked to OpenSSL version: OpenSSL 3.5.1 1 Jul 2025
01-Apr-2026 01:54:25.024 compiled with libuv version: 1.44.2
01-Apr-2026 01:54:25.024 linked to libuv version: 1.44.2
01-Apr-2026 01:54:25.024 compiled with liburcu version: 0.15.0
01-Apr-2026 01:54:25.024 compiled with zlib version: 1.3.1
01-Apr-2026 01:54:25.024 linked to zlib version: 1.3.1
01-Apr-2026 01:54:25.025 ----------------------------------------------------
01-Apr-2026 01:54:25.025 BIND 9 is maintained by Internet Systems Consortium,
01-Apr-2026 01:54:25.025 Inc. (ISC), a non-profit 501(c)(3) public-benefit
01-Apr-2026 01:54:25.025 corporation. Support and training for BIND 9 are
01-Apr-2026 01:54:25.025 available at https://www.isc.org/support
01-Apr-2026 01:54:25.025 ----------------------------------------------------
:
01-Apr-2026 01:54:25.093 zone 127.IN-ADDR.ARPA/IN: loaded serial 2007010100
01-Apr-2026 01:54:25.093 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1999012100
01-Apr-2026 01:54:25.093 zone localdomain/IN: loaded serial 2010110700
01-Apr-2026 01:54:25.093 zone 20.168.192.in-addr.arpa/IN: loaded serial 2019010100
01-Apr-2026 01:54:25.094 zone localhost/IN: loaded serial 1999012100
01-Apr-2026 01:54:25.094 all zones loaded
01-Apr-2026 01:54:25.094 FIPS mode is disabled
01-Apr-2026 01:54:25.094 running
assertion "!is_removal_owner(node)" failed: file "/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-cds/../../dist/src/rculfhash.c", line 1097, function "_cds_lfht_add"
Abort (core dumped)
---
Example output from "named-checkconf -z /etc/named.conf":
---
zone localhost/IN: loaded serial 1999012100
zone 127.IN-ADDR.ARPA/IN: loaded serial 2007010100
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1999012100
zone localdomain/IN: loaded serial 2010110700
zone 20.168.192.in-addr.arpa/IN: loaded serial 2019010100
/usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/mem.c:653: INSIST(_refs == 1) failed, back trace
0xb4ffd00f <isc_assertion_typetotext+0x7c> at /usr/lib/libisc.so.23
0xb4ffcf63 <isc_assertion_failed+0x33> at /usr/lib/libisc.so.23
0xb4ffae82 <isc__mem_destroy+0xdf> at /usr/lib/libisc.so.23
0x8c9aad <main+0x8a11dd> at /usr/sbin/named-checkconf
Abort (core dumped)
---
>Fix:
Unknown.
---
Izumi Tsutsui
>Release-Note:
>Audit-Trail:
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org, tsutsui@ceres.dti.ne.jp
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sat, 4 Apr 2026 06:35:37 +0900
> >Description:
> After upgrading my LAN DNS server machine from NetBSD/i386 10.1 to 11.0_RC2,
> named(8) crashes right after startup.
After several investigation, it turns out that the crash does not
happen immediately at startup. named(8) starts normally and reaches
"running", and then aborts as reported in the PR when it receives
a query that requires an outbound lookup to an upstream nameserver:
> ---
> assertion "!is_removal_owner(node)" failed: file "/usr/src/external/lgpl2/userspace-rcu/lib/liburcu-cds/../../dist/src/rculfhash.c", line 1097, function "_cds_lfht_add"
> Abort (core dumped)
> ---
The likely cause seems to be misalignment of dns_dispentry_t allocated
by isc_mem_get() in src/external/mpl/bind/dist/lib/dns/dispatch.c:
https://github.com/NetBSD/src/blob/netbsd-11/external/mpl/bind/dist/lib/dns/dispatch.c#L1453
>> dns_dispentry_t *resp = isc_mem_get(disp->mctx, sizeof(*resp));
On NetBSD/i386, the returned address is not 8-byte aligned,
per following printf outputs:
---
Index: dist/lib/dns/dispatch.c
===================================================================
RCS file: /cvsroot/src/external/mpl/bind/dist/lib/dns/dispatch.c,v
retrieving revision 1.13
diff -u -p -d -r1.13 dispatch.c
--- dist/lib/dns/dispatch.c 17 Jul 2025 19:01:45 -0000 1.13
+++ dist/lib/dns/dispatch.c 3 Apr 2026 20:13:47 -0000
@@ -16,6 +16,7 @@
/*! \file */
#include <inttypes.h>
+#include <stddef.h>
#include <stdbool.h>
#include <stdlib.h>
#include <sys/types.h>
@@ -1451,6 +1452,18 @@ dns_dispatch_add(dns_dispatch_t *disp, i
in_port_t localport = isc_sockaddr_getport(&disp->local);
dns_dispentry_t *resp = isc_mem_get(disp->mctx, sizeof(*resp));
+ fprintf(stderr,
+ "dispatch.c: dispentry layout "
+ "alignof(node)=%zu alignof(resp)=%zu "
+ "offsetof(ht_node)=%zu sizeof(resp)=%zu "
+ "resp_mod8=%lu ht_node_mod8=%lu\n",
+ (size_t)_Alignof(struct cds_lfht_node),
+ (size_t)_Alignof(struct dns_dispentry),
+ offsetof(struct dns_dispentry, ht_node),
+ sizeof(*resp),
+ (unsigned long)((uintptr_t)resp & 7),
+ (unsigned long)((uintptr_t)&resp->ht_node & 7));
+
*resp = (dns_dispentry_t){
.timeout = timeout,
.port = localport,
---
:
4-Apr-2026 05:11:55.200 running
dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=4 ht_node_mod8=4
assertion "!is_removal_owner(node)" failed: file "/s/netbsd-11/src/external/lgpl2/userspace-rcu/lib/liburcu-cds/../../dist/src/rculfhash.c", line 1097, function "_cds_lfht_add"
Abort (core dumped)
#
---
`dns_dispentry_t` contains `struct cds_lfht_node ht_node`, and
this node seems to (implicitly?) need to be 8-byte alignment
per liburcu requirements . If it is not properly aligned,
liburcu triggers an assertion in _cds_lfht_add() as noted above.
The misalignment appears to come from the non-"HAVE_JEMALLOC" path
in external/mpl/bind/dist/lib/isc/jemalloc_shim.h:
https://github.com/NetBSD/src/blob/netbsd-11/external/mpl/bind/dist/lib/isc/jemalloc_shim.h#L33-L54
---
typedef union {
size_t size;
max_align_t __alignment;
} size_info;
static inline void *
mallocx(size_t size, int flags) {
void *ptr = NULL;
size_t bytes = ISC_CHECKED_ADD(size, sizeof(size_info));
size_info *si = malloc(bytes);
INSIST(si != NULL);
si->size = size;
ptr = &si[1];
if ((flags & MALLOCX_ZERO) != 0) {
memset(ptr, 0, size);
}
return ptr;
}
---
On NetBSD/i386, sizeof(max_align_t) is 12 bytes so
sizeof(union size_info) is also 12 byets.
The returned addess of mallocx() calculated by `ptr = &si[1];`
is not 8 byte aligned.
Actually the following ugly patch fixes the assertion of _cds_lfht_add()
in liburcu:
---
Index: dist/lib/isc/jemalloc_shim.h
===================================================================
RCS file: /cvsroot/src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h,v
retrieving revision 1.4
diff -u -p -d -r1.4 jemalloc_shim.h
--- dist/lib/isc/jemalloc_shim.h 26 Jan 2025 16:25:37 -0000 1.4
+++ dist/lib/isc/jemalloc_shim.h 3 Apr 2026 20:13:47 -0000
@@ -30,9 +30,17 @@ const char *malloc_conf = NULL;
#include <stdlib.h>
+#ifndef ALIGNMENT
+#define ALIGNMENT 8U
+#endif
+#ifndef roundup2
+#define roundup2(x,m) ((((x) - 1) | ((m) - 1)) + 1)
+#endif
+
typedef union {
size_t size;
max_align_t __alignment;
+ uint8_t __roundup[roundup2(sizeof(max_align_t), ALIGNMENT)];
} size_info;
static inline void *
---
:
04-Apr-2026 05:13:13.869 running
dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=0 ht_node_mod8=0
dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=0 ht_node_mod8=0
dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=0 ht_node_mod8=0
---
Izumi Tsutsui
From: RVP <rvp@SDF.ORG>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@netbsd.org, kre@netbsd.org, christos@netbsd.org, mrg@netbsd.org,
joerg@netbsd.org
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sat, 4 Apr 2026 00:23:28 +0000 (UTC)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-510152587-1775262209=:18627
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
On Sat, 4 Apr 2026, Izumi Tsutsui wrote:
> The likely cause seems to be misalignment of dns_dispentry_t allocated
> by isc_mem_get() in src/external/mpl/bind/dist/lib/dns/dispatch.c:
>
> https://github.com/NetBSD/src/blob/netbsd-11/external/mpl/bind/dist/lib/dns/dispatch.c#L1453
>
>>> dns_dispentry_t *resp = isc_mem_get(disp->mctx, sizeof(*resp));
>
> On NetBSD/i386, the returned address is not 8-byte aligned,
> per following printf outputs:
>
> ---
>
> Index: dist/lib/dns/dispatch.c
> ===================================================================
> RCS file: /cvsroot/src/external/mpl/bind/dist/lib/dns/dispatch.c,v
> retrieving revision 1.13
> diff -u -p -d -r1.13 dispatch.c
> --- dist/lib/dns/dispatch.c 17 Jul 2025 19:01:45 -0000 1.13
> +++ dist/lib/dns/dispatch.c 3 Apr 2026 20:13:47 -0000
> @@ -16,6 +16,7 @@
> /*! \file */
>
> #include <inttypes.h>
> +#include <stddef.h>
> #include <stdbool.h>
> #include <stdlib.h>
> #include <sys/types.h>
> @@ -1451,6 +1452,18 @@ dns_dispatch_add(dns_dispatch_t *disp, i
>
> in_port_t localport = isc_sockaddr_getport(&disp->local);
> dns_dispentry_t *resp = isc_mem_get(disp->mctx, sizeof(*resp));
> + fprintf(stderr,
> + "dispatch.c: dispentry layout "
> + "alignof(node)=%zu alignof(resp)=%zu "
> + "offsetof(ht_node)=%zu sizeof(resp)=%zu "
> + "resp_mod8=%lu ht_node_mod8=%lu\n",
> + (size_t)_Alignof(struct cds_lfht_node),
> + (size_t)_Alignof(struct dns_dispentry),
> + offsetof(struct dns_dispentry, ht_node),
> + sizeof(*resp),
> + (unsigned long)((uintptr_t)resp & 7),
> + (unsigned long)((uintptr_t)&resp->ht_node & 7));
> +
> *resp = (dns_dispentry_t){
> .timeout = timeout,
> .port = localport,
>
> ---
>
> :
> 4-Apr-2026 05:11:55.200 running
> dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=4 ht_node_mod8=4
> assertion "!is_removal_owner(node)" failed: file "/s/netbsd-11/src/external/lgpl2/userspace-rcu/lib/liburcu-cds/../../dist/src/rculfhash.c", line 1097, function "_cds_lfht_add"
> Abort (core dumped)
> #
>
> ---
>
> `dns_dispentry_t` contains `struct cds_lfht_node ht_node`, and
> this node seems to (implicitly?) need to be 8-byte alignment
> per liburcu requirements . If it is not properly aligned,
> liburcu triggers an assertion in _cds_lfht_add() as noted above.
>
> The misalignment appears to come from the non-"HAVE_JEMALLOC" path
> in external/mpl/bind/dist/lib/isc/jemalloc_shim.h:
>
> https://github.com/NetBSD/src/blob/netbsd-11/external/mpl/bind/dist/lib/isc/jemalloc_shim.h#L33-L54
>
> ---
>
> typedef union {
> size_t size;
> max_align_t __alignment;
> } size_info;
>
> static inline void *
> mallocx(size_t size, int flags) {
> void *ptr = NULL;
>
> size_t bytes = ISC_CHECKED_ADD(size, sizeof(size_info));
> size_info *si = malloc(bytes);
> INSIST(si != NULL);
>
> si->size = size;
> ptr = &si[1];
>
> if ((flags & MALLOCX_ZERO) != 0) {
> memset(ptr, 0, size);
> }
>
> return ptr;
> }
>
> ---
>
> On NetBSD/i386, sizeof(max_align_t) is 12 bytes so
> sizeof(union size_info) is also 12 byets.
>
> The returned addess of mallocx() calculated by `ptr = &si[1];`
> is not 8 byte aligned.
>
> Actually the following ugly patch fixes the assertion of _cds_lfht_add()
> in liburcu:
>
> ---
> Index: dist/lib/isc/jemalloc_shim.h
> ===================================================================
> RCS file: /cvsroot/src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h,v
> retrieving revision 1.4
> diff -u -p -d -r1.4 jemalloc_shim.h
> --- dist/lib/isc/jemalloc_shim.h 26 Jan 2025 16:25:37 -0000 1.4
> +++ dist/lib/isc/jemalloc_shim.h 3 Apr 2026 20:13:47 -0000
> @@ -30,9 +30,17 @@ const char *malloc_conf = NULL;
>
> #include <stdlib.h>
>
> +#ifndef ALIGNMENT
> +#define ALIGNMENT 8U
> +#endif
> +#ifndef roundup2
> +#define roundup2(x,m) ((((x) - 1) | ((m) - 1)) + 1)
> +#endif
> +
> typedef union {
> size_t size;
> max_align_t __alignment;
> + uint8_t __roundup[roundup2(sizeof(max_align_t), ALIGNMENT)];
> } size_info;
>
> static inline void *
>
> ---
>
> :
> 04-Apr-2026 05:13:13.869 running
> dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=0 ht_node_mod8=0
> dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=0 ht_node_mod8=0
> dispatch.c: dispentry layout alignof(node)=8 alignof(resp)=8 offsetof(ht_node)=184 sizeof(resp)=200 resp_mod8=0 ht_node_mod8=0
>
> ---
> Izumi Tsutsui
>
It might actually be the max_align_t value on i386 at the core of this issue
as I found out some years back. I had a private discussion with some of the
gurus prior to filing a PR, but, there was no clear consensus (or even a palpable
fault at hand aside from my vague unease about the difference in the value of
max_align_t between GCC and NetBSD) then about what to do about this, and I
dropped it for lack of time.
I reproduce some of my emails below:
---START mail 1---
>From rvp@SDF.ORG Wed Oct 16 23:30:46 2024
Date: Wed, 16 Oct 2024 23:30:45 +0000 (UTC)
From: RVP <rvp@SDF.ORG>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: matthew green <mrg@eterna23.net>, Christos Zoulas <christos@netbsd.org>
Subject: Re: Header file changes of Tue, 08 Oct 2024
On Wed, 16 Oct 2024, Robert Elz wrote:
> I was a little surprised by the symlink implementation for <stddef.h>
> after the change, rather than the more traditional dummy include file
> that just has the appropriate include guard, and then
> #include <sys/me.h>
>
> I wonder if perhaps reverting to that method, with the guard that
> gcc is looking for (and what an absurd stupid way of doing anything
> that is, really!) in <stddef.h> but all (or most) of the contents
> in <sys/stddef.h>
>
Yes, this is fine, too.
On Wed, 16 Oct 2024, matthew green wrote:
> RVP writes:
>> ie. GCC keys on the include guard for this file. On Linux, I know, this file is
>> part of GCC and not glibc, so it's important; but, I'm not sure if this matters
>> on NetBSD (doesn't look like that file'll be used--except, maybe, when building
>> a/the compiler).
>
> actually, it's used for non-in-tree users:
>
> space-bird ~> pkg_info -L gcc12|grep stddef.h
> /usr/pkg/gcc12/lib/gcc/x86_64--netbsd/12.4.0/include-fixed/stddef.h
> /usr/pkg/gcc12/lib/gcc/x86_64--netbsd/12.4.0/include/stddef.h
>
> the -fixed one is modified ours, the other is the GCC one.
>
That's the same as on Linux where GCC is built using the standard 3-stage
bootstrap, which has a `fixincludes' phase. Here, (ie. on Linux, and also
the pkgsrc GCC), those include dirs will come first (gcc -v output):
```
GNU C17 (Ubuntu 13.2.0-23ubuntu4) version 13.2.0 (x86_64-linux-gnu)
compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP
[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/13/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
```
In the system GCC, however, the search path is quite different:
```
GNU C17 (nb1 20240630) version 12.4.0 (x86_64--netbsd)
compiled by GNU C version 12.4.0, GMP version 6.2.1, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP
[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/include/gcc-12 // <- doesn't contain stddef.h
/usr/include
End of search list.
```
In Linux, since glibc doesn't provide a stddef.h, _both_ the compiler and
the stuff it compiles end up using the same header (the gcc "fixed" one)
I expect the pkgsrc GCC is the same since the GCC header files get included
first.
But, with the system compiler, you get different values for `max_align_t' on
32-bit x86 depending on which header is picked up:
```
#include <stddef.h>
#include <stdio.h>
int main(void) {
printf("size_t = %zu\n", sizeof (size_t));
printf("ptrdiff_t = %zu\n", sizeof (ptrdiff_t));
printf("wchar_t = %zu\n", sizeof (wchar_t));
printf("max_align_t = %zu\n", _Alignof (max_align_t));
return 0;
}
$ cc -O2 -march=native -pipe -o x x.c
$ ./x
size_t = 8
ptrdiff_t = 8
wchar_t = 4
max_align_t = 16
$ cc -I/usr/src/external/gpl3/gcc/dist/gcc/ginclude -O2 -march=native -pipe -o x x.c
$ ./x
size_t = 8
ptrdiff_t = 8
wchar_t = 4
max_align_t = 16
$ cc -m32 -O2 -march=native -pipe -o x x.c
$ ./x
size_t = 4
ptrdiff_t = 4
wchar_t = 4
max_align_t = 4
$ cc -I/usr/src/external/gpl3/gcc/dist/gcc/ginclude -m32 -O2 -march=native -pipe -o x x.c
$ ./x
size_t = 4
ptrdiff_t = 4
wchar_t = 4
max_align_t = 16
```
_This_ is what prompted my initial email to you guys: GCC is compiled with one
value of `max_align_t', but, what it compiles uses a different value. Should we
worry? Or, am I just overly vexed about nothing?
Thx,
-RVP
---END mail 1---
---START mail 2---
>From rvp@SDF.ORG Thu Oct 17 23:34:52 2024
Date: Thu, 17 Oct 2024 23:34:51 +0000 (UTC)
From: RVP <rvp@SDF.ORG>
To: Christos Zoulas <christos@zoulas.com>
Cc: Robert Elz <kre@munnari.OZ.AU>, matthew green <mrg@eterna23.net>, Christos Zoulas <christos@netbsd.org>
Subject: Re: Header file changes of Tue, 08 Oct 2024
On Wed, 16 Oct 2024, Christos Zoulas wrote:
> Perhaps we should just fix max_align_t to match gcc's in our stddef.h and call it a day.
>
> typedef struct {
> long long __max_align_ll __attribute__((__aligned__(__alignof__(long long))));
> long double __max_align_ld __attribute__((__aligned__(__alignof__(long double))));
> /* _Float128 is defined as a basic type, so max_align_t must be
> sufficiently aligned for it. This code must work in C++, so we
> use __float128 here; that is only available on some
> architectures, but only on i386 is extra alignment needed for
> __float128. */
> #if defined(__i386__)
> #ifdef __clang__
> // 16 is the gcc alignment for __float128
> long long __max_align_128 __attribute__((__aligned__(16)));
> #else
> __float128 __max_align_f128 __attribute__((__aligned__(__alignof(__float128)))
> );
> #endif
> #endif
> } max_align_t;
>
That should be OK, too; but, clang defines that differently. Both FreeBSD and
OpenBSD use clang as the system compiler and they have these:
https://github.com/freebsd/freebsd-src/commit/5dd723425ee0bbe05c08d2c2272be9fc34695886
https://github.com/freebsd/freebsd-src/commit/31ad7c11b393583f7b6b1f8118b27a0339ccd71a
https://github.com/openbsd/src/commit/c9b8f0a24da6d4b249fcafbbc6a920bf0d985179
in addition to having a separate sys/_types.h header file.
Inspired by FreeBSD, I did a `tools + kernel' build just now (I need my old
and poky laptop for other work, so I can't do a full build and ATF test of
amd64/i386/xen*) with the following patch to both /usr/include/sys/stddef.h
and /usr/src/sys/sys/stddef.h.
Also, /usr/src/external/gpl3/gcc/dist/gcc/ginclude/stddef.h was moved out of
the way and a new stddef.h with just `#include_next <stddef.h>' put in place.
No problem with the build or with that kernel.
```
--- /mnt/usr/src/sys/sys/stddef.h.orig 2024-10-08 22:53:20.000000000 +0000
+++ /mnt/usr/src/sys/sys/stddef.h 2024-10-17 22:04:52.932348859 +0000
@@ -33,6 +33,7 @@
#ifndef _SYS_STDDEF_H_
#define _SYS_STDDEF_H_
+#define _STDDEF_H_ /* for GCC build */
#include <sys/cdefs.h>
#include <sys/featuretest.h>
@@ -68,11 +69,14 @@
#endif
#if (__STDC_VERSION__ - 0) >= 201112L || (__cplusplus - 0) >= 201103L
-typedef union {
- void *_v;
- long double _ld;
- long long int _ll;
+#ifndef _GCC_MAX_ALIGN_T
+#define _GCC_MAX_ALIGN_T
+#define __CLANG_MAX_ALIGN_T_DEFINED // XXX
+typedef struct {
+ long long __max_align_ll __aligned(__alignof(long long));
+ long double __max_align_ld __aligned(__alignof(long double));
} max_align_t;
#endif
+#endif
#endif /* _SYS_STDDEF_H_ */
```
-RVP
---END mail 2---
---START mail 3---
>From rvp@SDF.ORG Sun Oct 20 23:20:28 2024
Date: Sun, 20 Oct 2024 23:20:27 +0000 (UTC)
From: RVP <rvp@SDF.ORG>
To: Christos Zoulas <christos@zoulas.com>
Cc: Robert Elz <kre@munnari.OZ.AU>, matthew green <mrg@eterna23.net>, Christos Zoulas <christos@netbsd.org>
Subject: Re: Header file changes of Tue, 08 Oct 2024
On Fri, 18 Oct 2024, Christos Zoulas wrote:
> I think that we should follow suit with FreeBSD/OpenBSD which are very similar...
>
Yeah, we should follow the compiler definition--GCC in our case.
https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/__stddef_max_align_t.h
says: "Define 'max_align_t' to match the GCC definition.", but, GCC aligns to
16 bytes on i386--better not to change the ABI. (What to do about clang, then?)
Thx,
-RVP
---END mail 3---
---START mail 4---
>From rvp@SDF.ORG Mon Oct 21 22:54:13 2024
Date: Mon, 21 Oct 2024 22:54:12 +0000 (UTC)
From: RVP <rvp@SDF.ORG>
To: Christos Zoulas <christos@zoulas.com>
Cc: Robert Elz <kre@munnari.OZ.AU>, matthew green <mrg@eterna23.net>, Christos Zoulas <christos@netbsd.org>
Subject: Re: Header file changes of Tue, 08 Oct 2024
On Mon, 21 Oct 2024, Christos Zoulas wrote:
>> Yeah, we should follow the compiler definition--GCC in our case.
>>
>> https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/__stddef_max_align_t.h
>>
>> says: "Define 'max_align_t' to match the GCC definition.", but, GCC aligns to
>> 16 bytes on i386--better not to change the ABI. (What to do about clang, then?)
>
> I think that we should also special-case the i386 both in the clang and gcc cases, effectively
> providing the same max alignment for both compilers that the gcc header do.
>
Yeah, that's my preference as well. OK with mrg (GCC) and kre (standards)?
-RVP
PS. Apart from GCC/Clang, their C++ libraries, and GDB, max_align_t is hardly
used:
$ fgrep -r max_align_t /usr/src /usr/xsrc
[...]
/usr/src/external/mpl/bind/dist/lib/isc/netmgr/netmgr-int.h
/usr/src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h
/usr/src/lib/libc/tls/tls.c
/usr/src/libexec/ld.elf_so/tls.c
/usr/xsrc/external/mit/MesaLib/dist/src/vulkan/util/vk_alloc.c
$
so, an ABI change looks unlikely. And, aligning the TLS bits to 16-bytes on
i386 is also probably better anyway.
Thx,
-RVP
---END mail 4---
Note Jörg's point about GCC vs. SysV ABI difference (this is where I left off
due to lack of time then):
---START mail 5---
>From joerg@bec.de Tue Oct 22 12:33:25 2024
Date: Tue, 22 Oct 2024 14:33:11 +0200
From: Jörg Sonnenberger <joerg@bec.de>
To: matthew green <mrg@eterna23.net>, RVP <rvp@SDF.ORG>
Cc: Robert Elz <kre@munnari.OZ.AU>, Christos Zoulas <christos@netbsd.org>, joerg@netbsd.org, Christos Zoulas <christos@zoulas.com>
Subject: Re: Header file changes of Tue, 08 Oct 2024
Hi all,
the core issue is that GCC at least at the time tended to seriously
overalign long double. On i386 with the SYSV ABI that we use,
max_align_t should be 32bit. Note that Linux does *not* use the SYSV
ABI, but they silently switched a while ago because they couldn't get
GCC to implement the realignment stubs correctly for a long time.
Joerg
On 10/22/24 2:22 AM, matthew green wrote:
> cc: joerg, who had a better understanding of this than i do.
>
>
> .mrg.
>
>
> RVP writes:
>> On Mon, 21 Oct 2024, Christos Zoulas wrote:
>>
>>>> Yeah, we should follow the compiler definition--GCC in our case.
>>>>
>>>> https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/__stddef_max_align_t.h
>>>>
>>>> says: "Define 'max_align_t' to match the GCC definition.", but, GCC aligns to
>>>> 16 bytes on i386--better not to change the ABI. (What to do about clang, then?)
>>>
>>> I think that we should also special-case the i386 both in the clang and gcc cases, effectively
>>> providing the same max alignment for both compilers that the gcc header do.
>>>
>>
>> Yeah, that's my preference as well. OK with mrg (GCC) and kre (standards)?
>>
>> -RVP
>>
>> PS. Apart from GCC/Clang, their C++ libraries, and GDB, max_align_t is hardly
>> used:
>>
>> $ fgrep -r max_align_t /usr/src /usr/xsrc
>> [...]
>> /usr/src/external/mpl/bind/dist/lib/isc/netmgr/netmgr-int.h
>> /usr/src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h
>> /usr/src/lib/libc/tls/tls.c
>> /usr/src/libexec/ld.elf_so/tls.c
>> /usr/xsrc/external/mit/MesaLib/dist/src/vulkan/util/vk_alloc.c
>> $
>>
>> so, an ABI change looks unlikely. And, aligning the TLS bits to 16-bytes on
>> i386 is also probably better anyway.
>>
>> Thx,
>>
>> -RVP
>>
---END mail 5---
-RVP
--0-510152587-1775262209=:18627--
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org, tsutsui@ceres.dti.ne.jp
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sat, 4 Apr 2026 13:48:21 +0900
> It might actually be the max_align_t value on i386 at the core of this issue
> as I found out some years back.
It looks the problem is not "sizeof(max_align_t) on i386 is 12 bytes"
but "upstream lib/isc/jemalloc_shim.h (local implementation of
non-standard mallocx() and variants) assumes sizeof(max_align_t)
is power of 2 (or multiple of 8)".
Using in-tree jemalloc(3) by enabling HAVE_JEMALLOC explicitly in
src/external/mpl/bind/include/config.h also fixes the problem
(I'm not sure why it has been disabled by default):
---
Index: Makefile.inc
===================================================================
RCS file: /cvsroot/src/external/mpl/bind/Makefile.inc,v
retrieving revision 1.17.2.1
diff -u -p -d -r1.17.2.1 Makefile.inc
--- Makefile.inc 25 Aug 2025 16:17:25 -0000 1.17.2.1
+++ Makefile.inc 4 Apr 2026 04:38:31 -0000
@@ -17,11 +17,14 @@ CWARNFLAGS.clang+= -Wno-unused-value -Wn
LIBUVDIR= ${NETBSDSRCDIR}/external/mit/libuv
LIBUVOBJDIR!= cd ${LIBUVDIR}/lib && ${PRINTOBJDIR}
LIBURCUDIR= ${NETBSDSRCDIR}/external/lgpl2/userspace-rcu
+LIBJEMALLOCDIR= ${NETBSDSRCDIR}/external/bsd/jemalloc
LIBURCUMBOBJDIR!= cd ${LIBURCUDIR}/lib/liburcu-mb && ${PRINTOBJDIR}
LIBURCUCDSOBJDIR!= cd ${LIBURCUDIR}/lib/liburcu-cds && ${PRINTOBJDIR}
LIBURCUCOMMONOBJDIR!= cd ${LIBURCUDIR}/lib/liburcu-common && ${PRINTOBJDIR}
+LIBJEMALLOCOBJDIR!= cd ${LIBJEMALLOC}/lib && ${PRINTOBJDIR}
CPPFLAGS+= -I${LIBUVDIR}/dist/include
CPPFLAGS+= -I${LIBURCUDIR}/dist/include -I${LIBURCUDIR}/include
+CPPFLAGS+= -I${LIBJEMALLOCDIR}/include
CFLAGS+= -std=gnu18
LINTFLAGS+= -Ac11
@@ -61,6 +64,7 @@ LDADD+= -L${LIBURCUMBOBJDIR} -lurcu-mb_
LDADD+= -L${LIBURCUCDSOBJDIR} -lurcu-cds_g
LDADD+= -L${LIBURCUCOMMONOBJDIR} -lurcu-common_g
LDADD+= -L${LIBUVOBJDIR} -luv_g
+LDADD+= -L${LIBJEMALLOCOBJDIR} -ljemalloc_g
LDADD+= -lexecinfo_g -lelf_g -lkvm_g -lz_g -lm_g
.else
LDADD+= -lisccfg -ldns -lns
@@ -70,6 +74,7 @@ LDADD+= -L${LIBURCUMBOBJDIR} -lurcu-mb
LDADD+= -L${LIBURCUCDSOBJDIR} -lurcu-cds
LDADD+= -L${LIBURCUCOMMONOBJDIR} -lurcu-common
LDADD+= -L${LIBUVOBJDIR} -luv
+LDADD+= -L${LIBJEMALLOCOBJDIR} -ljemalloc
LDADD+= -lexecinfo -lelf -lkvm -lz -lm
DPADD+= ${LIBISCCC} ${LIBISC}
DPADD+= ${LIBUVOBJDIR}/libuv.a
Index: include/config.h
===================================================================
RCS file: /cvsroot/src/external/mpl/bind/include/config.h,v
retrieving revision 1.23.2.1
diff -u -p -d -r1.23.2.1 config.h
--- include/config.h 25 Aug 2025 16:17:26 -0000 1.23.2.1
+++ include/config.h 4 Apr 2026 04:38:33 -0000
@@ -225,10 +225,10 @@
#define HAVE_INTTYPES_H 1
/* Define to 1 if jemalloc is available */
-/* #undef HAVE_JEMALLOC */
+#define HAVE_JEMALLOC 1
/* Define to 1 if you have the <jemalloc/jemalloc.h> header file. */
-/* #undef HAVE_JEMALLOC_JEMALLOC_H */
+#define HAVE_JEMALLOC_JEMALLOC_H 1
/* Use json-c library */
/* #undef HAVE_JSON_C */
---
Izumi Tsutsui
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
tsutsui@ceres.dti.ne.jp
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sat, 4 Apr 2026 08:21:18 -0400
--Apple-Mail=_AEC57C7E-7F2B-4F99-98BF-90BE5986B909
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Apr 4, 2026, at 12:50=E2=80=AFAM, Izumi Tsutsui via gnats =
<gnats-admin@netbsd.org> wrote:
>=20
> The following reply was made to PR bin/60150; it has been noted by =
GNATS.
>=20
> From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
> To: gnats-bugs@netbsd.org
> Cc: netbsd-bugs@netbsd.org, tsutsui@ceres.dti.ne.jp
> Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 =
11.0_RC2
> Date: Sat, 4 Apr 2026 13:48:21 +0900
>=20
>> It might actually be the max_align_t value on i386 at the core of =
this issue
>> as I found out some years back.
>=20
> It looks the problem is not "sizeof(max_align_t) on i386 is 12 bytes"
> but "upstream lib/isc/jemalloc_shim.h (local implementation of
> non-standard mallocx() and variants) assumes sizeof(max_align_t)
> is power of 2 (or multiple of 8)".
>=20
> Using in-tree jemalloc(3) by enabling HAVE_JEMALLOC explicitly in
> src/external/mpl/bind/include/config.h also fixes the problem
> (I'm not sure why it has been disabled by default):
Great, thank you for finding the underlying cause, two questions:
1. Does anything need to be done with vax and sun2 that don't
use jemalloc?
2. Should we fix the custom shim that removes the power of 2
assumption so that it works anyway?
Thanks,
christos=
--Apple-Mail=_AEC57C7E-7F2B-4F99-98BF-90BE5986B909
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+BJlbqPkO0MDBdsRxESqxbLM7OgUCadECPgAKCRBxESqxbLM7
OqDeAJ4/9CGbgEGwXWc6DFyUqUlbSc/e1ACg83Qrpa4djhUwygi2uYD5mGnJZM4=
=iy8H
-----END PGP SIGNATURE-----
--Apple-Mail=_AEC57C7E-7F2B-4F99-98BF-90BE5986B909--
From: Jason Thorpe <thorpej@me.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
tsutsui@ceres.dti.ne.jp
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sat, 4 Apr 2026 05:28:37 -0700
> On Apr 4, 2026, at 5:21=E2=80=AFAM, Christos Zoulas =
<christos@zoulas.com> wrote:
>=20
> Great, thank you for finding the underlying cause, two questions:
> 1. Does anything need to be done with vax and sun2 that don't
> use jemalloc?
Re. sun2, we don=E2=80=99t even build BIND on that system.
<bsd.own.mk>
MKBIND.m68000?=3D no
I=E2=80=99m just about certain that today=E2=80=99s named would be too =
large to fit into the 24-bit address space.
-- thorpej
State-Changed-From-To: open->analyzed
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Sat, 04 Apr 2026 14:07:10 +0000
State-Changed-Why:
problem analyzed
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org, tsutsui@ceres.dti.ne.jp
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sat, 4 Apr 2026 23:16:02 +0900
christos@ wrote:
> Great, thank you for finding the underlying cause, two questions:
> 1. Does anything need to be done with vax and sun2 that don't
> use jemalloc?
Ah, I didn't notice it.
At least /usr/lib/libjemalloc.a of NetBSD/vax 10.1 doesn't
provide mallocx() and variants, so I'm afraid HAVE_JEMALLOC
won't work on such ports.
But it's too compilcated for me to understand what
src/external/bsd/jemalloc.old/include/jemalloc/jemalloc.h
stub provides..
> 2. Should we fix the custom shim that removes the power of 2
> assumption so that it works anyway?
I'm afraid this is the only option for forthcoming NetBSD 11.0.
(affects only i386? I don't know sizeof(max_align_t) values on
other ports)
Thanks,
---
Izumi Tsutsui
From: RVP <rvp@SDF.ORG>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sun, 5 Apr 2026 00:25:36 +0000 (UTC)
On Sat, 4 Apr 2026, Izumi Tsutsui wrote:
>> It might actually be the max_align_t value on i386 at the core of this issue
>> as I found out some years back.
>
> It looks the problem is not "sizeof(max_align_t) on i386 is 12 bytes"
> but "upstream lib/isc/jemalloc_shim.h (local implementation of
> non-standard mallocx() and variants) assumes sizeof(max_align_t)
> is power of 2 (or multiple of 8)".
>
Looks like the code is written to assume that `struct cds_lfht_node' will
always be aigned to lat least 8 byte boundaries:
src/external/lgpl2/userspace-rcu/dist/include/urcu/rculfhash.h:
```
49 struct cds_lfht_node {
50 struct cds_lfht_node *next; /* ptr | REMOVAL_OWNER_FLAG | BUCKET_FLAG | REMOVED_FLAG */
51 unsigned long reverse_hash;
52 } __attribute__((aligned(8)));
```
because the userspace-rcu code is using the lower 3 bits of the `next' pointer
as flags:
src/external/lgpl2/userspace-rcu/dist/src/rculfhash.c:
```
307 #define REMOVED_FLAG (1UL << 0)
308 #define BUCKET_FLAG (1UL << 1)
309 #define REMOVAL_OWNER_FLAG (1UL << 2)
```
and, when it isn't (as when the alignment is only 4 bytes--usual on 32-bit arches)
the address of the pointer will be taken as the REMOVAL_OWNER_FLAG flag bit and
the assertion seen will fire.
I feel this is an upstream code issue which'll affect any 32-bit arches, and
NetBSD's been unlucky to catch it because it is the only OS which runs BIND on
i386 and other 32-bits. Other mainstream OSes have dropped support for 32-bit
system for a while now (and OpenBSD doesn't ship with BIND--it uses unbound,
I believe).
So, ISC's custom mallocx() _must_ align any returned pointers to 8-byte
boundaries (at least). Must investigate why it doesn't when I have time...
-RVP
From: RVP <rvp@SDF.ORG>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Sun, 5 Apr 2026 10:51:36 +0000 (UTC)
On Sat, 4 Apr 2026, Izumi Tsutsui wrote:
> On NetBSD/i386, sizeof(max_align_t) is 12 bytes so
> sizeof(union size_info) is also 12 byets.
>
Yes, and `alignof(max_align_t)' is 4 which'll also stomp on the flag bits
encoded in the lowest 3 bits of the pointer address.
> The returned addess of mallocx() calculated by `ptr = &si[1];`
> is not 8 byte aligned.
>
Yes, it _must_ be at least 8-byte aligned, but on NetBSD/i386, as we've seen,
it isn't. Don't know what the reasoning behind the `max_align_t __alignment;'
there is. The usual way, if the pointer immediately following, should also be
aligned, is to do `alignas(max_align_t) ...' but this requires a C11 compiler.
In any case, someone should definitely ask the BIND people.
> Actually the following ugly patch fixes the assertion of _cds_lfht_add()
> in liburcu:
>
> ---
> Index: dist/lib/isc/jemalloc_shim.h
> ===================================================================
> RCS file: /cvsroot/src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h,v
> retrieving revision 1.4
> diff -u -p -d -r1.4 jemalloc_shim.h
> --- dist/lib/isc/jemalloc_shim.h 26 Jan 2025 16:25:37 -0000 1.4
> +++ dist/lib/isc/jemalloc_shim.h 3 Apr 2026 20:13:47 -0000
> @@ -30,9 +30,17 @@ const char *malloc_conf = NULL;
>
> #include <stdlib.h>
>
> +#ifndef ALIGNMENT
> +#define ALIGNMENT 8U
> +#endif
> +#ifndef roundup2
> +#define roundup2(x,m) ((((x) - 1) | ((m) - 1)) + 1)
> +#endif
> +
> typedef union {
> size_t size;
> max_align_t __alignment;
> + uint8_t __roundup[roundup2(sizeof(max_align_t), ALIGNMENT)];
> } size_info;
>
> static inline void *
>
I've fixed it slightly differently:
```
--- src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h.orig 2025-01-26 16:25:37.000000000 +0000
+++ src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h 2026-04-05 10:29:53.567824881 +0000
@@ -32,7 +32,16 @@
typedef union {
size_t size;
- max_align_t __alignment;
+ /*
+ * should be `alignas(max_align_t) char __alignment;', but this,
+ * using NetBSD's stddef.h, yields a 4-byte alignment (16 if you
+ * use GCC's own stddef.h).
+ *
+ * Remove uncertainty by explicitly padding to 16 bytes, ie. malloc(3)
+ * alignment. (Actually, the pointer following this header need only
+ * be 8-byte aligned.)
+ */
+ char __alignment[16];
} size_info;
static inline void *
```
HTH,
-RVP
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60150 CVS commit: src/external/mpl/bind/dist/lib/isc
Date: Sun, 5 Apr 2026 09:33:18 -0400
Module Name: src
Committed By: christos
Date: Sun Apr 5 13:33:18 UTC 2026
Modified Files:
src/external/mpl/bind/dist/lib/isc: jemalloc_shim.h
Log Message:
PR/60150: Izumi Tsutsui: Increase alignment so that libuv can use the bottom
3 bits.
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: analyzed->needs-pullups
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Sun, 05 Apr 2026 21:25:40 +0000
State-Changed-Why:
Confirmed src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h rev 1.6
fixes the problem on NetBSD/i386 11.0_RC3.
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Tue, 07 Apr 2026 10:24:05 +0000
State-Changed-Why:
[pullup-11 #251]
From: =?UTF-8?Q?J=C3=B6rg_Sonnenberger?= <joerg@bec.de>
To: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
tsutsui@ceres.dti.ne.jp
Cc:
Subject: Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2
Date: Tue, 28 Apr 2026 23:40:23 +0200
On 4/5/26 12:55 PM, RVP via gnats wrote:
> Yes, and `alignof(max_align_t)' is 4 which'll also stomp on the flag bits
> encoded in the lowest 3 bits of the pointer address.
Which is the correct value for the actual SYSV psABI on i386. Note that
GNU decided a while ago that they own the ABI and silently bumped the
alignment requirement to 128bit. Supposedly because they couldn't fix
stack realigment in GCC to actually work for like 3 release branches.
Joerg
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60150 CVS commit: [netbsd-11] src/external/mpl/bind/dist/lib/isc
Date: Wed, 6 May 2026 16:51:09 +0000
Module Name: src
Committed By: martin
Date: Wed May 6 16:51:09 UTC 2026
Modified Files:
src/external/mpl/bind/dist/lib/isc [netbsd-11]: jemalloc_shim.h
Log Message:
Pull up following revision(s) (requested by tsutsui in ticket #251):
external/mpl/bind/dist/lib/isc/jemalloc_shim.h: revision 1.6
PR/60150: Izumi Tsutsui: Increase alignment so that libuv can use the bottom
3 bits.
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.4.2.1 \
src/external/mpl/bind/dist/lib/isc/jemalloc_shim.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(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-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home