From nobody Fri Nov 21 04:16:55 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 4dCMPR5Kpnz6GT8d for ; Fri, 21 Nov 2025 04:17:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCMPR1cFSz3YyQ for ; Fri, 21 Nov 2025 04:17:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763698628; bh=070kO7JkSQgM3ShmMPuUWyw9eD6Z+b5gplEF7eM30rw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hVbnP2/JcKZURVci5fCnvrJ3DYXYYzueZIJpCvXcEQMhvOj7qSeb8TGSs2Sd4iCZJrhcJuY8cubvosuckT6aDweg8ZCfekEF09ErFMT34bCIBHQ0HvfkddI0yRnzDVpRGNJvL018e9kWcKHLv+s9C1N83F2K875V21+e3IGe2Ss5bkjTgZQ2TO23/agBFvHAQTmh1/NWdmmH/NrcJsdiL9deaRqDNS4xlMxOWzEYbsQOdJSwPkkB9G/jWL9gMugVst8IHT0prnXtveCKEqEbeVGVKQa+sfXGXUYZhzqblH3jvpdCOAh4acW532DCCMS0idDYiE5KGpzNsIdPp5VaiQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763698628; bh=RdWu5YJC5o6T7Z+l1Bmrr10j776EvO2lJEw1n24ptu6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=RpGyi3nU/qBKAEh8eOWDOBW/AmYz9HMXTbK+HhIwO/FrxQPc8O1+RgT2c33fUHBFyqsL7hcNPjK2yTbc06wv1QfGc2NonHlIF+pNPuWAuKhpoRB6ncrTP9aEQuSmxw1/zjnkkvtCqqm/m74N1tcfx25w6Q4q021zxYTolus26j1B9ihzJOcTCmF6d3lHruDsOfAaXchRbswUgVmi8+EJBx0z5Z6ipwjHLH3KZYgTWOL7WbRBqrBMcz1fQ4DqX1wxFEs7zhwi836u9Ci/Z3Jhhi6PO0asEz3JJQXihhY+K1/GSMTHvKvWAtkWWG6140T6TmFheCKmuSmENBn9o2LUJw== X-YMail-OSG: ErzyNU8VM1keAOpLX0LfRBlu0dqOcJFXg7sEL_jWLAB8e_pXk23L9A76U5CU_1r Ye7YRNE.Ihy5sSb_v8qwSTlaT3HKMaoMZLnZhsYLVx.4emu24QBswSpAphIaV5K1z371rK_XQqhJ 81a4CZlI_VC5NiY14cLZTYpdlx8OEnTjbUzdWLxLSbwidp7vp_cq2qHniiWwp.RCE1uO4kjK.SEn z_aaVKUPoggkGHrJnru5tBtOKXte4yCi1UTShUpjGNdlveTFn3rotXGFpn6jv6SCgdCJctvd8AxM kAcg_cIPGTSTDF_GFejj2wLBLx37f__5RJx_jpv1EmjPsgH5UxBd.PVKCBiF7JMUh1IwUtVnCSwA Ty9S3tb.Dk7b4wSpOq1gsUM8QraOwGjRVHu9H07uboN0l2tqqOWwvSEZyAJ1of8o2rWT77Zyhiph Eg3Sz1hFN3WM0qnGQG_lzQLG1WhfS6En6O4lCXBdBaJU3nrwLZw6Z26zDgwfyacBfFiz5434nUTt V3MNsBi2YOEoQhb._OF8.WvqScY24kBwoyC5tZL4cB1UBwvUoGu9zXz1WFr6dins2nNwE1PhT0on 2JYGkEkKEkgIksB5ZS44nc3V3tZ2ZAM1X_eHs3__YATD4bt7OY.Tce.1UkDODpzenYmLhdVsbdOG yEXl2zM9rPDa9vFq8QrXkpDsuiX05m9HNvjzWwLlVf6rvxf6krW0iZG.9KDqTSII69sPpy_rhufK 2yCcZnEIxGACtic9m6t4a.LvOFzz39IYwPekNoJY.P34NwD3rNj.Lo5rcu6B9WYMVRxsbYCa7Qmi WFA6Q2nW1Ecmnh7GUqlwWCxL92gVqpcd0o_7DqJjJCfJ9Br.nYJubvJHeh6xMTkKDdLo0lF4sLvl WjQurjv6i3Rib3.kSi7ZlYoylWWVuEPUQm5jZAC6actr.feaNLBqeHahXhQFALeV9SRJ1hejGYJs ffquZD6RY0NlrpAvDAmabnfHLZ.qCAkcJi2DP6DtNcu_w7k.P_AqwDywaOMj_Ejw5szd3aSaXnvW p9XiO6nQS4bFgRErx2CRt32nXArxwSFDm.2N8Hic1MaT4vv3V9bdlCIWHD5_oG1q.GPhw3MViPnR TbPjrrCrXDUnykJAto5k2W5rYT0yv1BMjWll7wikHQnRVB_S8plj2VQ3HJBmbkXAu5vqkj2zlBY9 540i9jQzx_Y_saTEoBGAfP0TKK.WFl.j9A_Vjbr.XWqRr7h89rLn_iKT7rnJbrKjvK3TVjzNAJPu lYk9GpDP2pUox46__gPvO4_RSEB_R749Y0scup58K.Irlsf.S6VyAW8DO8TCEkpJRuCkiEtzdxNj nXJ0pfcpTqY3mKaXnunPXFdY_CWvkTxBJnuOk7aSvkbP2Er4aJKpLYKO7C1R0S_hsGzepa.3RYCK bGmvj.pS6KS2BUzK2zL.Oy4qGGn2namDHrYybkwuae8TDgZKudRsTtZF6pGAMwGmzIAUnE3quN4L LwqUX_jvVKY8H_GKJ9u45Uo6ubVaM7bvD5E9_SVRbJzGah_Pd0KSflFISmcJuWAmQa0Xe7qgfAbF YBQf7EpV8uu0qJGRst5T0z.KwOBbkwpMpMlSF7RcM4yUWDhCt1_CRCMGHfnWgFJdQK9NEDfPn7Q_ Coij7yXU83djIAaC8DFq253kLrB_ZycHDwZ0XOfMM8LASG50j4zLVHXb8Gbg__tU7KEjoIrEombY m6LYA7eDsjwqA3Hoj5YhZJUoBUKYSS4UsnhXqVNseez6feIRaff7a80KSHZumUfwKfUHA4ZP.uUj YfeQLIgimx19IvIE2OAooNSr6qCi36FP3.J4D6PIjpP04eg3fzJ8jju.FO1xH9iCvCWZgdygHlsY myWT7Bvz3MN2IaoSB1cQiGBNlPCX.2dNBmGR.CNGMFT.GSbhlfzjLcsdO5jydZV4UDbJt9nLLG5s yqco.hL1WYDqdEke4b0oxSKRz2Gca5wsNeJA0kjs0qXLyemh706zQEYMatHoR5trJdBFaT3GZwE5 OmGhqvhYkWsMVSvYdWr7suFRcS.8eeWVter7DbyEjuQsPIhxZbljxFP7fawaJLVQuuT3Rkf.DPSR KceioHsEzQLiAVKtNg1BZJGnQ6EW_JaaKgDcpa9i7jkGXlR7I0JFliZexOAtMxeReoQM.kztfOTv SbNZHBfM5iD5xaXrC6Gl6lSAu2rK.0Va23Gxom1Dzy3t6NUfLcWVWjLnycW.2Nigd3BVqFLx38RQ wbs7RWtEnnRpQAbOBgf16fQu7wXjXY8ORcAv4k1befDTX6SJW5GcIdJZs.oUKjf.I40mwc_9KO5J IkQ-- X-Sonic-MF: X-Sonic-ID: 87744d6b-f5a6-4409-b624-3386a5698093 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Nov 2025 04:17:08 +0000 Received: by hermes--production-gq1-fdb64d996-zqbrv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 580ab0f7bfb76770d0545d8e2b382d81; Fri, 21 Nov 2025 04:17:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld From: Mark Millard In-Reply-To: Date: Thu, 20 Nov 2025 20:16:55 -0800 Cc: Warner Losh , "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <40BEA46A-96CE-46A1-A994-B8470EE0C844@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dCMPR1cFSz3YyQ 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. >>=20 >> Warner >>=20 >> 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 >>=20 >> +#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 >>=20 >>=20 >>=20 >=20 > 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=20 > 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?=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com