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

On 16.11.2025 18:51, 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

Unfortunately, that doesn't help. I'm out of ideas on how to debug this, 
all of my attempts have failed.

The problem only occurs when Clang compiles a larger project and is 
intermediate. Attempt to compile the clang generated reproducer is 
always successful.
It's clear that the parallelism introduced by make plays a significant 
role. But the system never reached an OOM condition before failure.

I would be grateful for any help and ideas on what to do next.
Michal

> 
> 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")))
>   #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
> 
> 
> 
> On Sun, Nov 16, 2025, 8:42 AM bob prohaska <fbsd@www.zefox.net 
> <mailto:fbsd@www.zefox.net>> wrote:
> 
>     On Sat, Nov 15, 2025 at 04:08:50PM -0700, Warner Losh wrote:
>      > On Fri, Nov 14, 2025 at 12:31 AM Herbert J. Skuhra
>     <herbert@gojira.at <mailto:herbert@gojira.at>>
>      > wrote:
>      >
>      > > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote:
>      > > >
>      > > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote:
>      > > > > Op 12-11-2025 om 23:25 schreef bob prohaska:
>      > > > > > For lack of any better ideas I've collected some of the
>     assertion
>      > > failure
>      > > > > > /tmp files by host at
>      > > > > > http://www.zefox.net/~fbsd/assertion_failure/ <http://
>     www.zefox.net/~fbsd/assertion_failure/>
>      > > > > >
>      > > > > > Thanks for reading,
>      > > > > >
>      > > > > > bob prohaska
>      > > > > >
>      > > > > >
>      > > > >
>      > > > > A really uneducated guess, but might the update of jemalloc
>     [1] have
>      > > introduced some subtle issues on armv7?
>      > > > > You can try reverting:
>      > > https://cgit.freebsd.org/src/commit/?
>     id=c43cad87172039ccf38172129c79755ea79e6102 <https://
>     cgit.freebsd.org/src/commit/?
>     id=c43cad87172039ccf38172129c79755ea79e6102>
>      > > .
>      > > > >
>      > > > What is the required syntax? Trying a simple
>      > > >
>      > > > root@generic:/usr/src # git revert -m 1
>      > > c43cad87172039ccf38172129c79755ea79e
>      > > > generated a torrent of conflict reports
>      > > > The source tree is expendable with no valued customizations.
>      > >
>      > > Try:
>      > >
>      > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8
>      > > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353
>      > > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102
>      > >
>      >
>      > Do you have to do all three? I'd have thought only the first one
>     would be
>      > needed.
> 
>     Necessary or not, it seems to have worked. No errors were reported and
>     buildworld/kernel has run successfully on two of three Pi2's. One of
>     them has rebooted and run an incremental buildworld using its new kernel
>     and world.
> 
>     Next step is to run make cleandir twice on that machine and try a
>     clean-start buildworld/kernel. Those results will take a few days.
> 
>     In the meantime, is there any explicit test to see if the reversion
>     worked as expected? Searching for null (no error) results is slow.
> 
>     For example, Peter Holm's stress2 suite found lots of mischief in
>     years gone by, might it be applied to this sort of problem?
> 
>     Thanks to you and everybody else for your help!
> 
>     bob prohaska
>