From nobody Sun Nov 16 21:11:15 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 4d8k7p5Bq9z6H6bG; Sun, 16 Nov 2025 21:11:18 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8k7p4hQ6z3PWW; Sun, 16 Nov 2025 21:11:18 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763327478; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=B+if8e3KuhPovBBBjlckAx7Y1V/Ducg2ltSt5Z27pQw=; b=sQkf47V0xQPXGP03V/0lFZ2nHKaDf03iT90B8N4kEeFXwZN+u+p9we2pr3w0I69galLfNx laIPUzQcL9gReFMXjnBtJVZjr+8x+4mibpXE5kOb5ZSfmI/tR6mTlk3ctUtaE9sSy1dKO/ J/tONpkHTDorENx6dKhOHeSrHtGRKZ9x5NgGd5iMV2Jbpawa0NMraK0aA5BAImkhC83KBo 8RAs+0eNSY15N4JfoITvSoI6/2KUEy+F6BrPddlzUyaFI9jjk+uYqvVNUvhRrc2ivTmhtD vONQdP723LqN6iMzRww5TyYA/vMCGGhu9YchlO5zcz0RenFmNsxAJt2D82rKzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763327478; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=B+if8e3KuhPovBBBjlckAx7Y1V/Ducg2ltSt5Z27pQw=; b=lNpF502+LVKSpF1DkUx7NYEsnSQ6r/CuMXdSL+wIfnha7pmTizAtdZMksxlW5fszn+qonP P2TLuMx+w3mjq1PqiAulktW9yFIVXFinmNhJbYLMc3LsI7nyo/3CehACvWyivKuIYo7kDm qwCkpNukZ1fpWUwMv0Z9NG/kJ5ji4VQWkHHn0v18V+yiVz0y/a417ik6jOgIIyLVVcFfZ/ 8vfM13Xt3vjzsdShhZkn4XRN9zcH91VgjFRengqPgmNMux0Ldci9KHZ+glH0yMNh73oAtL W9tcljGYFY0JcJ/q3iHbqh/23yjirmS7AYSzpyujHVgJuS9IH3ktrFLAvmz/Qw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763327478; a=rsa-sha256; cv=none; b=i/s54jcdQ/qHEfqnrsBok6CMeyKAlVNJaJTIk/16tcSX2hvVPawKNff7FOi1GM99rd+iAv UA1SmxCTXcdTXE50ssC6tbawdCdDaAHNPqpyIFGr3FDB5m5lJEQIHKcmOdUdYr04zLtdwa VqfKsvlzQqUwi97Y8CBvkkZuTlP+7QCKgPKdOi9YMjPtXtirTeLHNbl5n2bv/Z/mACYvs5 oDCT7ZN7kbH/1x/7YXWOfND+0jeF1HlXwJwDe+KUysR0LCi+TLYmbZOiEXpsxKKdUhLqqw XSr8txMOd0Fr1d8bvoh8i8Twm5DOyvOF6yUaRPGQ0l2AaEM+13EH3vuY92knxg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:67c:14a0:5fe0:5d57:b56d:2102:8df5] (unknown [IPv6:2001:67c:14a0:5fe0:5d57:b56d:2102:8df5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d8k7n3cNnz10L0; Sun, 16 Nov 2025 21:11:17 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> Date: Sun, 16 Nov 2025 22:11:15 +0100 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 User-Agent: Mozilla Thunderbird Reply-To: mmel@FreeBSD.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: Warner Losh , bob prohaska Cc: "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> Content-Language: cs, en-US From: Michal Meloun In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > 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 > > > > 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/ 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 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 >