Re: bin/60150: named(8) crashes at startup on NetBSD/i386 11.0_RC2

["RVP via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60150; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Cc: gnats-bugs%netbsd.org@localhost
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