From nobody Fri Nov 21 14:55:40 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dCdXk6Y5Sz6HJTR; Fri, 21 Nov 2025 14:54:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCdXk2Wv2z3jjw; Fri, 21 Nov 2025 14:54:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5ALEtfC9070898 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 21 Nov 2025 06:55:41 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5ALEte2K070897; Fri, 21 Nov 2025 06:55:40 -0800 (PST) (envelope-from fbsd) Date: Fri, 21 Nov 2025 06:55:40 -0800 From: bob prohaska To: Mark Millard Cc: Warner Losh , "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> <40BEA46A-96CE-46A1-A994-B8470EE0C844@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BEA46A-96CE-46A1-A994-B8470EE0C844@yahoo.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dCdXk2Wv2z3jjw On Thu, Nov 20, 2025 at 08:16:55PM -0800, Mark Millard wrote: > On Nov 20, 2025, at 19:34, bob prohaska 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