Date: Fri, 21 Nov 2025 06:55:40 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: Warner Losh <imp@bsdimp.com>, "Herbert J. Skuhra" <herbert@gojira.at>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: <aSB9bPbs9QsDb1vR@www.zefox.net> In-Reply-To: <40BEA46A-96CE-46A1-A994-B8470EE0C844@yahoo.com> References: <aO068RrAehdiHOoZ@www.zefox.net> <aRUJPryA4Vmu8dDD@www.zefox.net> <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <aRalt0YwsjV_mvMq@www.zefox.net> <87ldk9f4tt.wl-herbert@gojira.at> <CANCZdfrSaJ7snshhiV2r%2BEX_sazhJ-HFAK0e=q%2B-MOmP=uLKqg@mail.gmail.com> <aRnxOtZ8W2g6ZkVF@www.zefox.net> <CANCZdfqTZ311DGEQmH0FLKrh8csN-P=qwUt=RXGSTrehUfZi3g@mail.gmail.com> <aR_dxBLhRtcBq5k1@www.zefox.net> <40BEA46A-96CE-46A1-A994-B8470EE0C844@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 20, 2025 at 08:16:55PM -0800, Mark Millard wrote:
> On Nov 20, 2025, at 19:34, bob prohaska <fbsd@www.zefox.net> 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 bob@pelorus.zefox.org:/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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aSB9bPbs9QsDb1vR>