Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld

On Thu, Nov 20, 2025 at 08:16:55PM -0800, Mark Millard wrote:
> On Nov 20, 2025, at 19:34, bob prohaska <[email protected]> wrote:
> 
> > On Sun, Nov 16, 2025 at 10:51:01AM -0700, Warner Losh wrote:
> >> Maybe try main with the following patch. Adrian noticed the TLS mismatch. I
> >> don't think it will matter, but TLS thread model stuff always gives me a
> >> big headache. If the following fails to apply, just copy the
> >> JEMALLOC_TLS_MODEL line from i386 to arm. The default changed elsewhere,
> >> but this wasn't updated here.
> >> 
> >> Warner
> >> 
> >> diff --git
> >> a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
> >> b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
> >> index 34c86271ab2e..bd6850ebd95f 100644
> >> --- a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
> >> +++ b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
> >> @@ -26,10 +26,11 @@
> >> #undef LG_SIZEOF_LONG
> >> #undef LG_SIZEOF_INTMAX_T
> >> 
> >> +#define JEMALLOC_TLS_MODEL     __attribute__((tls_model("initial-exec")))
> >> +
> >> #ifdef __i386__
> >> #  define LG_VADDR             32
> >> #  define LG_SIZEOF_PTR                2
> >> -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec")))
> 
> I'll note that I've recently reported getting the
> jemalloc assertion failure for i386 now and it already
> had
> 
> __attribute__((tls_model("initial-exec")))
> 
> before (and after) this patch. Thus using such is not
> sufficient to avoid the assertion problem on its own.
>
 
It's unclear to me if the problems extend to platforms with long-term prospects
of support by FreeBSD. i386 is already unsupported, armv7 likely headed that way.
ISTR you replicated problems using aarch64, but I think it was serving as a host
OS to something older. (I understand only a tiny fraction of what you've reported)
 


> >> #endif
> >> #ifdef __ia64__
> >> #  define LG_VADDR             64
> >> @@ -38,7 +39,6 @@
> >> #ifdef __sparc64__
> >> #  define LG_VADDR             64
> >> #  define LG_SIZEOF_PTR                3
> >> -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec")))
> >> #endif
> >> #ifdef __amd64__
> >> #ifdef _USE_LG_VADDR_WIDE
> >> @@ -47,7 +47,6 @@
> >> #  define LG_VADDR             48
> >> #endif
> >> #  define LG_SIZEOF_PTR                3
> >> -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec")))
> >> #endif
> >> #ifdef __arm__
> >> #  define LG_VADDR             32
> >> @@ -69,11 +68,9 @@
> >> #ifdef __powerpc64__
> >> #  define LG_VADDR             64
> >> #  define LG_SIZEOF_PTR                3
> >> -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec")))
> >> #elif defined(__powerpc__)
> >> #  define LG_VADDR             32
> >> #  define LG_SIZEOF_PTR                2
> >> -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec")))
> >> #endif
> >> #ifdef __riscv
> >> #  define LG_VADDR             48
> >> 
> >> 
> >> 
> > 
> > Is it still advisable to apply this patch? I'm guessing it'll get committed on its
> > own in due course. Its present lack seems harmless.
> 
> The i386 example assertion failure indicates that the tls_model
> being initial-exec is not sufficient to avoid the problem in
> general.
> 
> Warner could have other reasons to want the patch in place for
> all I know, not that I consider that likely.
> 

So the assertion failure in jemalloc is hardware-independent? Good if correct.

> > One of the Pi2's has now completed two complete cycles of self-hosting, with no 
> > problems of any kind. No silent hangs, no assertion failures. The double-cleandir
> > rebuild also worked with no difficulty. It even seems to boot a little faster 8-)
> 
> I assume this is main 16 built with the normal debug build
> style, not 15.0 which has assertions disabled in its build
> and not some older version of FreeBSD that does not have
> the code at all? 
> 

The host in question reports:
bob@pelorus:/usr/src % uname -a
FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #7 main-n281932-07e6bfeae5a1: Thu Nov 20 12:10:30 PST 2025     [email protected]:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
bob@pelorus:/usr/src % uname -KU
1600004 1600004

The sources are unmolested apart from reversion of the jemalloc commit as
suggested by Warner..


> > More seriously, is the path forward even hinted at yet?
> 
> My activities, while of some use, are unlikely to identify
> the actual problem(s) or the fix(es): I do not have an
> appropriate type of background knowledge.
> 
> I do not even know if the assertion is being tested for
> an inappropriate context vs. an appropriate one.
> 
> > It seems jemalloc is
> > getting considerable attention but I'm not reading reports of 'Eureka!'.
> 
> The attention is because the error report is from jemalloc
> itself, for its internal checks of its own operations. And
> it is not the kind of report that would be likely to be
> blamable on code that calls into jemalloc from outside
> jemalloc.
> 
> > Am I
> > right in thinking git will preserve the reversion when pulling other updates?
> > Does anything special need to be done if an updated jemalloc is committed to
> > -current?
> 
> If you restore the original code in your source tree,
> you will then be back to getting what has been committed
> as of the time you update in the future.

Thank you!

bob prohaska