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

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.

>> #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.

> 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? 

> 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.


===
Mark Millard
marklmi at yahoo.com