From nobody Mon Nov 17 01:14:17 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 4d8qXF4r4Mz6GCn6; Mon, 17 Nov 2025 01:14:21 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8qXF064Dz3qTF; Mon, 17 Nov 2025 01:14:20 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=qZ3e+yji; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="t XOxm/u"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.154 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id EB7F97A014F; Sun, 16 Nov 2025 20:14:19 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sun, 16 Nov 2025 20:14:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1763342059; x=1763428459; bh=ttZv1GbhU6oLWBxnyEkgQVlihXGBL3yW eaSIz4cYp2s=; b=qZ3e+yjiqjrhaSoYsPvjWiPz7HIPgcqGb0eht4Y/t0UFzYbh hrcf+kjSUpHCkU2Lc0+GFVfjZ3/rJbcj37jd3RqeYe15ccFAFBDmkPi90eLObskI h54RsSQ8hwKfLrnpUb/+YasiriFIKtXX2jTNkqpVnVqDfs7RqqlCBZhBUFIg84ng A6lfhYadQHGk7k/2dI2dXpxfR1cB4gQjtbabZKJ3KdalRNz/uoHFpis0oy7/3wFi cxwsRNV0pfiro+vXHmAWI/svOaAVwEKceoF6ZDMed5E7Azr0EIU1jbGomd+ulzT6 jFUN4HxAUbB1iwYSm8LOhFvNdz6LuBOm7VExzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1763342059; x= 1763428459; bh=ttZv1GbhU6oLWBxnyEkgQVlihXGBL3yWeaSIz4cYp2s=; b=t XOxm/uU7DI/uDjRKuT/qecXB2VjIPRy9GkaKv0CxKZtOVUbzB3boDT9d6163mW2y Rn09xMWL075UYiIJI75e2J3wn3QppQSxLTj1WXSH1yE95C4zfMLS28ZUfxn4ETHS 2USrZlnA0qrSmqg3Cqul7+wR9i66y/6SctQ4TvLrg1dvhSiDyDf/qj1+0N+nZ2J/ k/viyeGjgTEftAPkVnTj/PJTbJ9cRbF4KMxXywK70ott4GaVS0cOXF2iFmvWjBIW qQPn8SfLJ/0VTrf6RoLyxHiSXr70XXEiGgmM802PblgBmb9IylNp3IGpHofi4qGb V+ZiOnLOW6kQarXtssujw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvudejudduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfggtggusehttdertddttd dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv rhhnpeehvedvveevgffggfdvfeeifedufeehhfdtleejtdehveetuefhgfelieelkeegue enucffohhmrghinhepshihshdrmhhknecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepvd dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehfrhgvvggsshguqdgrrhhmsehfrh gvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 16 Nov 2025 20:14:19 -0500 (EST) Date: Mon, 17 Nov 2025 01:14:17 +0000 From: void To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: WITHOUT_CLEAN confusion in -current Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org 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; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.154:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4d8qXF064Dz3qTF Hi, The context this was tested in was armv7. Not tested in others. Sources are n281932 2025-11-16 When running 'make -j2 -DNOCLEAN buildworld' the warning "make[2]: /usr/src/Makefile.inc1:482: warning: The src.conf WITHOUT_CLEAN option can now be used instead of NOCLEAN." is emitted (but the build continues and the warning seems harmless) After stopping the build and adding WITHOUT_CLEAN to /etc/src.conf and starting it again like so: 'make -j2 buildworld' the build fails with make: /etc/src.conf:7: Invalid line "WITHOUT_CLEAN" in /usr/src/share/mk/src.sys.mk:24 in /usr/src/share/mk/local.sys.mk:58 in /usr/src/share/mk/sys.mk:283 make: Fatal errors encountered -- cannot continue -- From nobody Mon Nov 17 02:03:50 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 4d8rdh3ZNLz6GHwp; Mon, 17 Nov 2025 02:04:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8rdg6ZTTz3vRw; Mon, 17 Nov 2025 02:04:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AH23ow3041259; Mon, 17 Nov 2025 04:03:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AH23ow3041259 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AH23owI041258; Mon, 17 Nov 2025 04:03:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 17 Nov 2025 04:03:50 +0200 From: Konstantin Belousov To: Michal Meloun Cc: Warner Losh , "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> <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d8rdg6ZTTz3vRw On Sun, Nov 16, 2025 at 10:11:15PM +0100, Michal Meloun wrote: > > > 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. Is the problem reproducable on armv7 userspace running on arm64 kernel, or only on native armv7 host? From nobody Mon Nov 17 03:04:12 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 4d8szN0MTLz6GNhg for ; Mon, 17 Nov 2025 03:04:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 4d8szM6Qbbz44N9 for ; Mon, 17 Nov 2025 03:04:31 +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=1763348665; bh=vSD/yS6F3nu2V9iozH5CUbe3hIVq7BWDw2Ufoi4oFdI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WyTrxJNBKpjeMhPF3UVz96lz/g0VbXo2LAXzn58rYDER4ULB0Odp2vV0tlZwV8BjnRGKwOxbHdl2UcbP9EFB7lrSwlcEVUY18k10U4vEnxBKwRuFtsDmCCkMR4PNqZ4Nea+Ar4x40Gfzk1c+uw9V8zjtiTzq12F9TBH3OgOxsudVK8XXK6Culwp4P0tc/6Equka4FetH1TWGKLIAFyUfn6HLtkMd+0O1PBvWS9yxT9hLXYYpjnmm0yfEWRdEj0Q7hkJPkt8BU+lbP5nibt+zLpipf8HI137RvF+951cZm9TwBPDtkkh889c9Uvgtb6OjLdiYeLXso6ve5Fb2WBMj4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763348665; bh=nFEwTdnaDGCddhEcv8Abeo+qnWMT6cAoOPUFMWhZ51B=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jsUS4muQAbk4sFliRSUYLoIecgjIpST6zQANoZOg0dkqlSjZgwlVsUVUKsJyvfGbEEK4G/0z0CsbNLXZmzLLg8q5LMPi/ZV8q+RYf6hELxqaWurUKIG2HpDjiNtPpcBXbp5Fwe8+x28XjhWPuGn70ex0U96j/qjiv4LT9LP2gEynpbQuaMHdJJPAR1Gn1PrSwBnWEa8BeocB/xkxajLgN3/0DAI5cLFKZHSP0MqnrFQrxICuE7u1xgCQ/KDWM2JjqUbrBkJmmQHMzkDMt6X88ka44sZ/LR/O04jkm7q3B9FCyPEujPU4nskyDes8qlZLh7FIwh5lYzt8cqXc79heew== X-YMail-OSG: usHENEAVM1kuhELk5kP8b4pGT_hgW_gC4I_Cq03f65vTJUExakLpEnIqN9t9F0Q FMatVkbEQdUxVZhZR.gNmaIgOnYrwziXFbc26CwaZQ5Kr62xt43fSMUlaZWt34TNVablJ7lnSAz5 GNjntjBYmzAJYG_fEL_rMdGAG9TpsYFJ6xaM7uur2SZrPRRHz66MKq_x7h9xZUOHBHKDi7QCaGCf jJelEUp3io4Q2cslwCnyl5Slw8YDyxHaN1rJWr4zJddrIhu0x_JLdwylsfo9JtsRs4AsgFv.i.5d qT3IzrVBXL.QomZtQGAz64HjnEx8uJRCShPUxuBRcCmrD4vK8NrIhcx_p2eioDg1PrLoM3U36Wf4 7beq722drfn9Ahf5aWM7d9NVEvo1w5tT4X_jZK3psXrAn_cM5VjZKxviFUMOkuyzVEME5EnHqSbH amQf5GNMdFOO5BDd_4v6QyL2HHovw8JxDrVm4a0fYF0JY6dV9BHLTSWONE1fEHD8wS7vo4s81dDn 87N_4gBdqB2jTP0RZt7NCMq8MhTmkSrdAfEHpZRkq.2KKW1Lg5l2dlglyTULROGtQtCRe5IAvLia qVYTxwRsXtVjjqiVKGeghxOUhJroEQE3WQBtr0cVVZA9Vmqv16a7tqga8t1nou9vP7W4l_RaU787 eb7uz0dKXGIWqiPQCDEnT26r3tiZyhToxAGFF85qY_EPpQ.BqucQmOeSa7nWNkh.yMigC1FLFaep ahlD4QbokBs_59gQ1uMOs4h4c8Kojs3tWKJ6mVYkvLXClWl2bFQUsTuazj1YKQzciCN3WRtBUTtQ ab8gn9PbewDsfpVNStd.JK8t79AY5os5p.hvWxBW_5Sld23l8DtVHEwYGuGUoYR6xdkNc37raf4E P7kOObG2q5HXICWw2KuXQyQuH1wF4agJ65JGcnsY54KrWFOasZDndD7PM2PyjUVVfrpW2LxcQ5Lm AnQkcPUr26pd_.tavMh6Y0Dk19.HCcAta87de_mUQuKYAwUgj_i_XZL3AKSLVQZMhp_5x4x6QPCP e1onLHdqOFcvMJQE8nB4vMLPlpGlJKCRpUCmHRVHuulmjPhSXBvRzhdkDJyVnd6vg.vkYKYyZgYG OC.QXUpvmwcB33ds6oBCBH4qLNaBVYDqn_kged7wExIbI8Tggvnfa2xwzMLCOJ1CzV3XBMnBiVYL S8H5vUhImZ8xhxxVlZYRaIvcfYfSuvXkspUcm2BuFehRGtEgc2VmxsxldOiUO0CSU4b2oAl0ZM9J PiURABbQavoWEAAmVKh.9GK0oDr4gyKmAa6e89I2S5EOroFCsjHx3090xZ7rbk6.QVzvg6.nZfkn gK2WW_DU9KkEpQ2xrDToTYQXRzHpD_lS6cQh_yRCn85piAofrIwM34wgcjV4tHdL.Z7mXL21CgMZ fagw80eeyjQAyt1N4TdMb7S9iMAHRn5qKkWMB89dRQAKz_IQNBxF9jFR3HSNZHNiw0B..MauQhNt VkKXWH5KGc6w2MgUuasPzft1IbgPKiDDVAooQ2fPkL9Dz0Qnjj_99EMDSfnRiGbcpIwsjDc3SRub kzI.ym1Hn4cZgKFrlVPI4MUwlFgDO_hnmF1BSa0gqxm3DVM1LBv0pgDTeApWDP2YHjbfPPtLOTSG T3OqJjdciNHNsUqqHExTTN5qgV6AGfe1bwx7jO0x5MO2vds5vCKybzRj5akWCf0zLWbj5ganAQ12 _IZLrx.0QXEbC0WP82ZSpA19ohba3f3XFZbAiIxtCMSVSFHp4wpz9Om_G.0WZZyTajbpNYRWmGhp PmSumV.sl3jhGByvqaH3Ak74juweLEOXRuI9wAY4Cs9nqRCQO0KBZ8SEBJzFKd54Q3RUZoyIAZbw sfGLM1kDIrOSh7iZ2AFOILgcACB7MoCNxo5umaKA5mASr685B3TnMekgaAAlgFCcw0vRMGmE7.xi _UM9vVJflRS8j3jcLpTiXT4rINqm17dFMGd4qCBvnhAnphbdMt3.dzLD9xGuHfEIRhvtwYuZwnfv kSY3UJwKXdh747KX4WaSm9q4DDsOiyMO_A9bvTn2XTRaODghY.eLmZYEbVt.XqV3wToq8QFinsJ5 xXbyVRESVQpf16Q9mvaA4uO5MuVGPPRbUsNT3uA6pJKZWzrkmwJNRGHVmPuOyDpf8DBoIQUK5gxS Xsupga.kk2fphVdjodulk528X3g6x3l275KQgB9_1WLcIFnRryJoQKoMRWKbc6NNV4YMJ72uyf9R YjL1mZIf84_DQHW.IYNJLm_uFfRaJqYtjQE6.XolsSf.LdOuORJPPArw2XWKVyJOM3a4OijBf6RH RyDs- X-Sonic-MF: X-Sonic-ID: eb8b2ccd-17a4-47d0-aa7b-d0904d436490 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Nov 2025 03:04:25 +0000 Received: by hermes--production-gq1-76c986f798-th5cb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 524f9784749b61c0631b69963c406174; Mon, 17 Nov 2025 03:04:23 +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: Sun, 16 Nov 2025 19:04:12 -0800 Cc: Michal Meloun , Warner Losh , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> To: Konstantin Belousov X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d8szM6Qbbz44N9 On Nov 16, 2025, at 18:03, Konstantin Belousov = wrote: > On Sun, Nov 16, 2025 at 10:11:15PM +0100, Michal Meloun wrote: >>=20 >>=20 >> 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. >>>=20 >>> Warner >>=20 >> Unfortunately, that doesn't help. I'm out of ideas on how to debug = this, all >> of my attempts have failed. >>=20 >> 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. >=20 > Is the problem reproducable on armv7 userspace running on arm64 kernel Yes, I've replicated the problem on a Windows Dev Kit 2023 in an armv7 chroot with the system boot's having hw.physmem=3D2G via /boot/loader.conf and the SWAP space sets to 3.5 GiBytes. "env META_MODE=3D make -j8 buildworld" was executed in the chroot until it failed with the assert Bob P. has been getting. The aarch64 system was an installation of an official pkgbase distribution, not a personal build. Same for the world in the chroot. All main [so: 16 at this point]. Absent the memory pressure from the small hw.physmem, I did not get the failure. I also tried experiments with aarch64 doing an armv7 buildworld with some small sizes for hw.physmem . I got no failures. So far, only armv7 has been shown to have the issue. =20 > , or only > on native armv7 host? The armv7 kernel does not need to be involved at all: just the armv7 world. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Nov 17 05:57:18 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 4d8xq745Tfz6GdFM; Mon, 17 Nov 2025 05:57:39 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8xq65ymgz3Nx3; Mon, 17 Nov 2025 05:57:38 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=MBO0001 header.b=pexc1XN7; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 80.241.56.171 as permitted sender) smtp.mailfrom=herbert@gojira.at Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (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) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4d8xq2401Hz9tKQ; Mon, 17 Nov 2025 06:57:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gojira.at; s=MBO0001; t=1763359054; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VxQFoxZaRwoqdCdiJGubw8Gr8r7PvvHLlUEgDZ7S9iU=; b=pexc1XN7YQtuWb5iv+cwQ1az4cfjUQy5mi+oz9A7PuXSr+1bgzKTrnpLIuzJsnqPRCYTED tfpR2EcJMmou53QFTXbWDcz5Bdj9k86xkOtPX2CGsvO3XWMNIp8xCT+7sUJ90d78oWf02m 75G5UKxN2kXZg/4tAINhNn4nb1JCHLQY85IabGnMwIJyncQOT+8fL/K7AaF2x5GQ6rqq/r NbQFxOBcJ4N5OGrSkj8Uu8XEh/g0pq2k048y/UTK8WSA3x3COlvY7wcR+vMrNOmJTWOkqn NxoGCJK+yLY8ILNxDY6Nu43i05K8/Ge5jpemEoHbafOLLvmlwBqjdGrUwJ+3cQ== Date: Mon, 17 Nov 2025 06:57:18 +0100 Message-ID: <87h5ut8am9.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: WITHOUT_CLEAN confusion in -current In-Reply-To: References: 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 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=MBO0001]; R_SPF_ALLOW(-0.20)[+ip4:80.241.56.0/21]; RCVD_IN_DNSWL_LOW(-0.10)[80.241.56.171:from]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:199118, ipnet:80.241.56.0/21, country:DE]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[gojira.at]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gojira.at:+] X-Rspamd-Queue-Id: 4d8xq65ymgz3Nx3 On Mon, 17 Nov 2025 02:14:17 +0100, void wrote: > > Hi, > > The context this was tested in was armv7. Not tested in others. > Sources are n281932 2025-11-16 > > When running 'make -j2 -DNOCLEAN buildworld' the warning > > "make[2]: /usr/src/Makefile.inc1:482: warning: The src.conf WITHOUT_CLEAN option can now be used instead of NOCLEAN." > > is emitted (but the build continues and the warning seems harmless) > > After stopping the build and adding WITHOUT_CLEAN to /etc/src.conf > and starting it again like so: > 'make -j2 buildworld' > > the build fails with > > make: /etc/src.conf:7: Invalid line "WITHOUT_CLEAN" > in /usr/src/share/mk/src.sys.mk:24 > in /usr/src/share/mk/local.sys.mk:58 > in /usr/src/share/mk/sys.mk:283 > make: Fatal errors encountered -- cannot continue I guess the line in your /etc/src.conf is wrong (e.g. missing "=", etc.). From nobody Mon Nov 17 06:29:07 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 4d8yWj1CjSz6Gg0G for ; Mon, 17 Nov 2025 06:29:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8yWg5R84z3V5B for ; Mon, 17 Nov 2025 06:29:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=LOA2Epo4; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102d) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-34381ec9197so3561319a91.1 for ; Sun, 16 Nov 2025 22:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1763360954; x=1763965754; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=naD5cPuAhzHVs/J0c83WLLvCtWzpfRGhZ1PPcfzo/zQ=; b=LOA2Epo4BRhBAngDOGWWTmAlKlT9DtBWFiDm1P66R17cW3iOkD4qmm7jw89jTLor87 npykudyxoBmP0reG5zGl5Ezz74BNIcLERlJHGE6+KLIaJ5PkzwYDcQISUG/RGu0GCBjJ 3xHyjHaADf4CByU+cJGE4WtZnHLWuo8qB2LJHfxygMRzcfNWZ1n65Gm6Dj8mHi8Kyd3Y pW7v5lzFDnRDCkkvnCE7gddeJ556zlMTukdzCNSjN5cB/RaDZdl3Zjr3a47K0H0suYAb G0OdlaW/qYHTgiE/PCmJYl2vmmiEchEJ93xI4jMJkaI/XbLTz7ESdZAzNZFhUxlIyU0k DLSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763360954; x=1763965754; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=naD5cPuAhzHVs/J0c83WLLvCtWzpfRGhZ1PPcfzo/zQ=; b=vfnKgdgZSdiM/W0knzzcvpDFkIVQmGjxLko7yJpcuQTLQjLzOeIu0/FaOcrPdP7jy7 NZqUIIBZcZ4a5Em03XFgUXrWK5z/IHhFi8WXNhAzQphB7l1tMj9a6VZzie4gjsnJ7bbD tSdY7UFCdrVR8Z+tThrAciPKKsD0q+Qf4XOIipNgCeWNCUIxj8GMX/qUcLWoTZnT5Psu ap6OHF3wNgXRPM8CDfG2LEtZ+9ZrGn6nI/Lr/4P8567ulGe/UGM0yspKmF/mM17FIfJj yDGMjbl4rifECEHm172U+hRFgjmzX5VuOmuCA4lGgijcrs386/f/nEYJyFpYCyrxdqpR Le0w== X-Gm-Message-State: AOJu0YyQYoORcw/K/bUEzIQn3Z0e9hCeC1FyXSyUwHqr+uO+xVHlTSZQ vfleIth/NwKImCdV4ZY7EWpHeZV5qmhv8AaMSCHv9hlBug8WQHTCF7qYP0h8x7hEAlleU2q1Lga zZkzXO5oTKrmMPYgJWOOFaZF776Un+u0VHwLCjuJ2cP/x3/ZnF3PtEzY= X-Gm-Gg: ASbGnct4IzYmydC4/gx5xtu6z0HrV3tAgE3HIZIy0u8NkXpn1fBqL99RquL2cRiYELM 2OdCHnCfcJTw9nlsyzEPZMZgBT7WaVDc4SQCOsF3oRVwWKZigV0lngSXKVIHciHTRIUPalunjNx 4F7S6+/da/mYj1iCiaDzg2Ih4f0HPQmsg1XSoC4hlu25bGEzqgGSHrEHFvtILPwpgktfQzLbd7Y dKXpjBL1EZpCK9XxNHzspp9mSxTbPAx+Eh8W0tz/SEJjUkgoDfbp/hOxdRJgBZNBUo8BgE= X-Google-Smtp-Source: AGHT+IETwaJ6n1Iv2pCbUtZ815t4ciZVSujGcnrFnfwRnqe3yPpXvqNZO6UmGI2UjUvrJlq4davgbhJJOyowLV2Xq84= X-Received: by 2002:a17:90b:4c51:b0:341:c964:125b with SMTP id 98e67ed59e1d1-343fa7326bbmr11622935a91.31.1763360953641; Sun, 16 Nov 2025 22:29:13 -0800 (PST) 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 References: In-Reply-To: From: Warner Losh Date: Sun, 16 Nov 2025 23:29:07 -0700 X-Gm-Features: AWmQ_bkhE3J--jXFfdCq-btdxyz5ePJLaRMlcLuUJB-71a4cV7_lcRaWlTdTiQQ Message-ID: Subject: Re: WITHOUT_CLEAN confusion in -current To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000040bcda0643c477aa" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102d:from]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4d8yWg5R84z3V5B --00000000000040bcda0643c477aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 16, 2025 at 6:14=E2=80=AFPM void wrote: > Hi, > > The context this was tested in was armv7. Not tested in others. > Sources are n281932 2025-11-16 > > When running 'make -j2 -DNOCLEAN buildworld' the warning > > "make[2]: /usr/src/Makefile.inc1:482: warning: The src.conf WITHOUT_CLEAN > option can now be used instead of NOCLEAN." > > is emitted (but the build continues and the warning seems harmless) > > After stopping the build and adding WITHOUT_CLEAN to /etc/src.conf > and starting it again like so: > 'make -j2 buildworld' > > the build fails with > > make: /etc/src.conf:7: Invalid line "WITHOUT_CLEAN" > in /usr/src/share/mk/src.sys.mk:24 > in /usr/src/share/mk/local.sys.mk:58 > in /usr/src/share/mk/sys.mk:283 > make: Fatal errors encountered -- cannot continue As others have pointed out, this is almost certainly because you're missing a "=3Dy". You can keep using -DNOCLEAN, at least for as long as the warning is there. IT's what I use, though WITHOUT_CLEAN=3Dy is the default these days. Warner --00000000000040bcda0643c477aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Nov 16,= 2025 at 6:14=E2=80=AFPM void <void@f-m.f= m> wrote:
Hi,

The context this was tested in was armv7. Not tested in others.
Sources are n281932 2025-11-16

When running 'make -j2 -DNOCLEAN buildworld' the warning

"make[2]: /usr/src/Makefile.inc1:482: warning: The src.conf WITHOUT_CL= EAN option can now be used instead of NOCLEAN."

is emitted (but the build continues and the warning seems harmless)

After stopping the build and adding WITHOUT_CLEAN to /etc/src.conf
and starting it again like so:
'make -j2 buildworld'

the build fails with

make: /etc/src.conf:7: Invalid line "WITHOUT_CLEAN"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in /usr/src/share/mk/src.sys.mk:24
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in /usr/src/share/mk/local.sys.mk:58
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in /usr/src/share/mk/sys.mk:283
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make: Fatal errors encountered -- cannot = continue

As others have pointed out, this i= s almost certainly because you're missing a "=3Dy".

You can keep using -DNOCLEAN, at least for as long as the w= arning is there. IT's what I use, though WITHOUT_CLEAN=3Dy is the defau= lt these days.

Warner=C2=A0
--00000000000040bcda0643c477aa-- From nobody Mon Nov 17 08:24:16 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 4d914h4N0bz6GqgN for ; Mon, 17 Nov 2025 08:24:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 4d914h2rk1z3fHH for ; Mon, 17 Nov 2025 08:24:36 +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=1763367870; bh=c7SiVbMBbMYN/a/KM7vJ5QBh2obZBCsrNRlB4LVUyLs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=b/rQ6czKcM1QcZ9VHuZ8p58MFASMEJqfwEw/+Drk3vR0yQcUebgJ4S23r1+PuoTrGrUflVT8/TK6CqEW5bzVbwn7d4oWS4p4DyU0WGcwV2I4aSV/EyBB90w+/tQFgjsDhSwrjniHXQKBnKv6DkIr5XuZjVeFaxVjypPpUKq9sVWgvczR8Rsu1Db/jPIArVZI0/Jo0xx9SmAnJLFsnaVHFVWif747N1IeNIz2sQUhlV58LevzYKh95mHmc3bGQXpkMjzjRCZAt0/jommB+wwWLmJgxK00/TrObOF83E3Bk9hTsAFDZIBXtgFXYWvn5ynCI2myWEIxTHtgoCbxqM7yxg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763367870; bh=FVExrfxJ8KEQH4Junpi8cCSUyY2Lw7gH03sqqoLbqPb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JrMY1ylCsJ71MX1vhWXb6wwUpckjeduWYyJE1mwOIQYwyesna9WGCI3oK0B8n7v0vw+Yg1BVSzVTJgmLgvDrihwxkgV72322SbM9f3aUvVxNzY5U98ZSaMVLPy2py0Cnbk5BEV4KCU5EbF0Du8RSWwqo9fJDfgq/ENiCzQzU1hBves5FKNtMrNahxm05pG4UzK7ANJ/t2hr9ZNGd1DLVS9bvcEC+76dBDVIPlXtD3FycFJoD/bXqa0yOXxkW0QoYD+wStfO3uCqJ1+cIG/TA16Q3/08UgQBB6jwIP8/Xh+eSjKyUHmFHkHM/ezXo3hW0IPbZM+xWPpr8v0+Qoh/a2g== X-YMail-OSG: w5hrrxoVM1mGkq_d.Ft6crl0SHRWM86JeS5Tz51RIX9igC5nBmoloGMuj3yW_Rb GeUoIjagz9LC_0ywhFmINCs7RkwS6FX5RcBr.YKSikhlM1e5wY_M36_3b5DmtIATXnH2Wc05xP56 kzLQA_IIM7ZJ1kQ0EJqwW4nbw1vL3c4NXeQCjYX3WeX136Q4NarZUD07_0EMptRD9QWk9dRQTM6Z 6UpHbm0L7UaLXrQlSwGBIMQNweeNGTp4TzYheuoqNVbGK_131QwXxsir5xUSJDIWB5ZDa15OEC6h DrYllIzLEe.Cj2PMSil_7VxUvJdvHV3ZLWbA3C6d_wNP0fesSZyc9.REd4yAXqB4hM28V0blNDD0 d_HdWV.YnMqoe84XalVo_SLgDcDt0265XxGaZ9VoQigYH5RVsWb7V.oPue4GohNVKz48upmQ4SyO y0rKZCzq16gqaftUf_GkcOmyLWe5c.edpCDNOgU8wnZNY30GJXbWZZqiOEO1kr8XhxU.BSSH86tD 7GGW2RgcCgKYBaM_5QnzQbY3.D8IJwTtzu.8fw3nYCPyUuy7h_W79G3Ono9ytRCbfsMBwkx3_UP4 Zm4ggTu1vhRx1hIbvsmzlrgiUbF1DKono5a8890AKoHSt7etYfWGwxisSHYwRL2g3L56aoREkkky kFFXD3A4cyM4V0ErfLWb5mVXv4HXTa25uDrW18AFeHTByFEfAmv1rqMyz4eD7iilwcKzrCoZhcjn T6qTXckhKdqqwDLZXDbJpu4vCadjZiWAmw0z_F2cuMrNsEXA1V5dW2_IPez5kjD_sFVygSE35jS3 _9pNTBorj.hLo3PnXV5GT3v1CnYAHfzMsLm0jac_BS0agnwD0nOeTcleWisywuiPunByck1c39k4 L9Jxcxs5GIq7c4YLfejEHo24ocf3SFtmVO24aZR5rwFwGVFrtGhHmhpw7PQm5oQoA5ii.56g4Rde VN8MwEAuzBay2okvie54TppL6vtlQQuow2QRWWrSMzSTE8vZlcT2DpZF91NY3y.bxykxHWdirnKA Yno1k4LdQGGw.7767fpUTZn.moNYeFdxgV3uQEoPJyL9_5.SEjHhIZG2p0PUk.w96Rl6Iq10F4TY bFmhasZvLnY0A.rTmouV9AwgRNeI0WJyp8bOVUF3v0oORhwV8rQ4GdXy8fuLIic8hV2qxlsYRmV7 fmpvmoJa_cR4sxtoIZy1BOMkvP_oTVychdOcFIWv4SiAzmJM89tIm0GTuHtSccEcNPdm8Jx4Xope pJTbM3VWf6Y.u24OuOvIzxbdolmPIwwuLblW4AkJ8j2Dnd5wtOeLbKT9243H9Im.QbpqOt4ZLEcZ byhgmvigQO.0KFQl5pQwcgyI15j51yTlK0.Cpso6x1O3.oEZS89NMYiLx2m0QtDbTBi3a03UBIcE Q20ljbuD1VMGvptv7LAo4E84974mc14.8KE0uboKeW2guZ4UCXMKhD7iLMSxfJ6SYq_HNdz4U_nr iLUeFL2zRupBWcMnNQ7oq4KPspEVifrPOyKwcvRzLIN7vhXFD0SkxkG4Nt0xKWFo5HtRDIJBzGrh 02qw4tvPPv0xP9HjUcElFg4.9XqAeRrQohrtGu8csKWdpJOzBEkmDmIZL1bv3MmXUHQZ9tbn__DR RU1LpYBi_HDRd4JGqBAZQ4_.Fh5CnaPXJDL1cdNET73Q9SUBIXCXHIYRJRsdj6JJuLkusCrAWH7i yjd.ZW2iy4ePC2fu9D7LwYnnDmUzcpKCBAQhbpt63_.XOwGOA6JI.S6c.n3TgvjRanHeUf6Gp6kH aSZ_KRw4p1H_6.il7XaxA4tf4wfxs1vy2fhwl4Fe.K6LZtVQOVSVOXQ9.FdNiBaKSjQojGuvH85m voLO0k3M54Korm6WGuufRs4V6FuJf6nK.LZOsMtUvt17zC8NcpbT87LLi9mKWamMjjJ0DlLU_xpC O31xPlo3EzhD7LvPeZ9OTEufc4nbLOT8wyY2B6EfqYs8eUKkrYHyXM_43VQbKV.5CslBRgRlgROO Ic_es0ych3SAl0_8fISute3hrog0xiHaGjZzkLa8MYk3XXup3xjFMS8V6hIGNlrVbRyzA1zxXgvn x6mdiHgCnZUZP1HfX3_t.mksLb5Bu3Jv7RIso6O5kRnGy9.P51MThALxH7vRvgqT5zZS6AJ8y3wC PcEl3YdhsjrdrGeI7Z_CfSk2xL7YZiDCZoUiF5iG2afFfrcCXIRsnM5Il95tZlKXY00pb.l.EkWM .C9lQOLbV5yzwGZDIeD24DQNVipWS0IJPnAy9XItF_sT2J96pHjph22Qm8rYlk_2r4nqe4a2aVvd bJpzpXYwiHOiCpT8- X-Sonic-MF: X-Sonic-ID: 8c7a6069-93ad-4c0f-9248-219ab76086e9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Nov 2025 08:24:30 +0000 Received: by hermes--production-gq1-76c986f798-mdv7f (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2d7425a1f9eaa190a7cd2694305d740e; Mon, 17 Nov 2025 08:24:27 +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: <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> Date: Mon, 17 Nov 2025 00:24:16 -0800 Cc: Warner Losh , bob prohaska , "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <0157ECE7-759F-4C00-9656-CB2ECA65E19E@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> To: "mmel@freebsd.org" 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: 4d914h2rk1z3fHH On Nov 16, 2025, at 13:11, Michal Meloun wrote: > 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 >=20 > Unfortunately, that doesn't help. I'm out of ideas on how to debug = this, all of my attempts have failed. >=20 > 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. >=20 > I would be grateful for any help and ideas on what to do next. > Michal [Note: The context is an official pkgbase distribution context and so the /usr/src/ is not tied to git. /usr/src-investigation/ is a copy of /usr/src/ that was then modified. Also, this is via a armv7 chroot on the aarch64 Windows Dev Kit 2023, not via armv7-only hardware.] The crude hack reported later below has shown the first failure indicated as happening during base_alloc_edata by reporting: p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x11u as the failure message. # diff -u /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h = /usr/src-investigation/contrib/jemalloc/include/jemalloc/ --- /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h = 2025-11-12 02:24:28.000000000 -0800 +++ = /usr/src-investigation/contrib/jemalloc/include/jemalloc/internal/ehooks.h= 2025-11-16 23:47:10.965711000 -0800 @@ -1,6 +1,7 @@ #ifndef JEMALLOC_INTERNAL_EHOOKS_H #define JEMALLOC_INTERNAL_EHOOKS_H =20 +#include #include "jemalloc/internal/atomic.h" #include "jemalloc/internal/extent_mmap.h" =20 @@ -158,6 +159,7 @@ * This isn't really ehooks-specific (i.e. anyone can check for zeroed = memory). * But incorrect zero information indicates an ehook bug. */ +__attribute__ ((visibility ("internal"))) extern volatile sig_atomic_t = which_base_extent_context; // HACK FOR DEBUGGING USE static inline void ehooks_debug_zero_check(void *addr, size_t size) { assert(((uintptr_t)addr & PAGE_MASK) =3D=3D 0); @@ -167,7 +169,45 @@ /* Check the whole first page. */ size_t *p =3D (size_t *)addr; for (size_t i =3D 0; i < PAGE / sizeof(size_t); i++) { - assert(p[i] =3D=3D 0); +switch (which_base_extent_context) +{ +case 0x10u: // base_alloc + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x10u); + which_base_extent_context=3D 0x0u; + break; +case 0x11u: // base_alloc_edata + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x11u); + which_base_extent_context=3D 0x0u; + break; +case 0x12u: // base_new + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x12u); + which_base_extent_context=3D 0x0u; + break; +case 0x13u: // base_boot + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x13u); + which_base_extent_context=3D 0x0u; + break; +case 0x20u: // extent_commit_wrapper + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x20u); + which_base_extent_context=3D 0x0u; + break; +case 0x21u: // extent_commit_zero + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x21u); + which_base_extent_context=3D 0x0u; + break; +case 0x22u: // ecache_alloc_grow + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x22u); + which_base_extent_context=3D 0x0u; + break; +case 0x00u: // None known + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x00u); + which_base_extent_context=3D 0x0u; + break; +default: // Some other context + assert(p[i] =3D=3D 0 && which_base_extent_context !=3D 0x00u); + which_base_extent_context=3D 0x0u; +} + //assert(p[i] =3D=3D 0); } /* * And 4 spots within. There's a tradeoff here; the = larger # diff -u /usr/src/contrib/jemalloc/src/base.c = /usr/src-investigation/contrib/jemalloc/src/base.c --- /usr/src/contrib/jemalloc/src/base.c 2025-11-12 = 02:24:28.000000000 -0800 +++ /usr/src-investigation/contrib/jemalloc/src/base.c 2025-11-16 = 23:50:14.396483000 -0800 @@ -1,3 +1,4 @@ +#include #include "jemalloc/internal/jemalloc_preamble.h" #include "jemalloc/internal/jemalloc_internal_includes.h" =20 @@ -340,12 +341,15 @@ b0get(void) { return b0; } + +__attribute__ ((visibility ("internal"))) volatile sig_atomic_t = which_base_extent_context=3D0x0u; // HACK FOR DEBUGGING USE =20 base_t * base_new(tsdn_t *tsdn, unsigned ind, const extent_hooks_t = *extent_hooks, bool metadata_use_hooks) { pszind_t pind_last =3D 0; size_t extent_sn_next =3D 0; +which_base_extent_context=3D 0x12u; =20 /* * The base will contain the ehooks eventually, but it itself is @@ -476,12 +480,14 @@ */ void * base_alloc(tsdn_t *tsdn, base_t *base, size_t size, size_t alignment) { +which_base_extent_context=3D 0x10u; return base_alloc_impl(tsdn, base, size, alignment, NULL); } =20 edata_t * base_alloc_edata(tsdn_t *tsdn, base_t *base) { size_t esn; +which_base_extent_context=3D 0x11u; edata_t *edata =3D base_alloc_impl(tsdn, base, sizeof(edata_t), EDATA_ALIGNMENT, &esn); if (edata =3D=3D NULL) { @@ -523,6 +529,7 @@ =20 bool base_boot(tsdn_t *tsdn) { +which_base_extent_context=3D 0x13u; b0 =3D base_new(tsdn, 0, (extent_hooks_t = *)&ehooks_default_extent_hooks, /* metadata_use_hooks */ true); return (b0 =3D=3D NULL); # diff -u /usr/src/contrib/jemalloc/src/extent.c = /usr/src-investigation/contrib/jemalloc/src/extent.c --- /usr/src/contrib/jemalloc/src/extent.c 2025-11-12 = 02:24:28.000000000 -0800 +++ /usr/src-investigation/contrib/jemalloc/src/extent.c = 2025-11-16 23:49:55.820658000 -0800 @@ -1,3 +1,4 @@ +#include #include "jemalloc/internal/jemalloc_preamble.h" #include "jemalloc/internal/jemalloc_internal_includes.h" =20 @@ -90,11 +91,14 @@ assert(edata =3D=3D NULL || edata_guarded_get(edata) =3D=3D = guarded); return edata; } + +__attribute__ ((visibility ("internal"))) extern volatile sig_atomic_t = which_base_extent_context; // HACK FOR DEBUGGING USE =20 edata_t * ecache_alloc_grow(tsdn_t *tsdn, pac_t *pac, ehooks_t *ehooks, ecache_t = *ecache, edata_t *expand_edata, size_t size, size_t alignment, bool zero, bool guarded) { +which_base_extent_context=3D 0x22u; assert(size !=3D 0); assert(alignment !=3D 0); witness_assert_depth_to_rank(tsdn_witness_tsdp_get(tsdn), @@ -1114,6 +1118,7 @@ bool extent_commit_wrapper(tsdn_t *tsdn, ehooks_t *ehooks, edata_t *edata, size_t offset, size_t length) { +which_base_extent_context=3D 0x20u; return extent_commit_impl(tsdn, ehooks, edata, offset, length, /* growing_retained */ false); } @@ -1297,6 +1302,7 @@ bool extent_commit_zero(tsdn_t *tsdn, ehooks_t *ehooks, edata_t *edata, bool commit, bool zero, bool growing_retained) { +which_base_extent_context=3D 0x21u; witness_assert_depth_to_rank(tsdn_witness_tsdp_get(tsdn), WITNESS_RANK_CORE, growing_retained ? 1 : 0); =20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Nov 17 09:15:13 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 4d92CN6KdQz6GvcD for ; Mon, 17 Nov 2025 09:15:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 4d92CM1p8Tz3lrt for ; Mon, 17 Nov 2025 09:15:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NKiXDjCr; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763370925; bh=fUXWt3VXnuDVo7J/NwtiWE3t5+EmNbuptEyICtk2t4s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NKiXDjCrK3F5Ea/OMALnpctB5O+51DKIOxZzNgJA/oer8oXzTnhFCLhB0utK2AjDvl+n1R6Mw3B8chfQalrFjHUbaoO38q3eFpluYQFYfaEE+u8HEH5X9ir6ceyLli1tke4/+RhaZi07BAsaHntbYyPiGkZIwslEHhhDsTGpAr2qsTmn0+ABeClQi2Y1oiaxtVkJNs+UZZB+Fg65heUerENZePQuARZN77sn5HwTNnDD6dyaB/NBVdRiWrwNLe2xUFBEP7PO/oggnjq8GjNT/78Wmqhv1rv97wBDH9v4u6Zxhox2PnJJjYEsnr2yX2AzMdae25cXpqP5dDcN3WdeLw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763370925; bh=54C25OWGAkbKSknwyARZ7P/n3yCPtypmi5YsgV/R/4P=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Kgw6fdNjBGOhMmNhE63AtrgOBT213Zmr7DNkUW8jzhoyAdHqv0VuEd/WD8wSEhNdywGHO7fH0L27EBed9LFiFMGpZ50kZzz9veTrwdA7UxEVTtjxf8nlm8JvDsqTd/4Dw7fWyTHLFP3nWRKpa2SnKZ2lCGwXflaEkPLSnsyOvuOoj/oPw5v2sDJyr/mZcOuObR6Opj6r0u/tqshj6FcQOhxXMxtKvEyW9ykFOakKd4DYP64L2Ci1Dmtr0FwHjyEJZ1pllx0K9Ln1Pr8zSLQl/eTz5Sn5Sj9ojBBQgB2G0lJlBYM4tPlNJ6oNKnV7vKSfMqvwweES+fWrisHMfSpjaw== X-YMail-OSG: cjNYDjYVM1nXKuHEOt99QUiPYq7v.dTsPDBzueJhSwlgbxO26xScvCp0igBeL0i zJV8HxgP81jO5BtnOpIQ2c2fiufM3Cy3g7UGqkPxWHBvRdeS9c7rIW3z4PF642kUu8RlK5qvV6UE c_998py.AIofbNmUE.0TivRdWWZIznewX07IJshfsaT3xZ2DiDcYwllQdW1WejHmZ.HWM8peZvnl OCMG0iegeeFelhrMhEeJHpDwuQo2KVm1gYHSYLV1jVuje2zEwGSfIteUw1l6Gk0XDtNUMbJ_7AQ5 1_5z8pyGDKA433b8b7SUFxbrFXehdg6qj59YVAGqr3wwRM7Z_sEjzVt.YxAAdeIdt5P5d3mHr4r9 YrDCs3zcauq43bdn0JdxcMW6.9U8B6TC9Gfy9e55wR_vWGsMY0x0QjFlcOlnbV3Hzubk69lVk2VS HMeFsMZiQWcPHbHzA6MASESwBC4Zmj.wYUuee1M1LpLKG5CwgTDZ9sNWHYK2ea8xd7YaVkmwa7x0 fdDu.6g5cD3ij1HXKaNdepb248MbkfAw2m0AMtew8NU0vp2xpYI_a0XDPp0ndFAUs5jgfGiYuIty Pi.VRBHy9QNSPSaUfkhOWIpJUz0SqzXB2oqeph0O25FfsAUoss5w6PltJci6C_5By0olsRQp4gEp od7G88NYaQOEIDDpAKaoAGd1sIQTynRtmAqbNdnQu5C2keprE1uowpRS7kdzScD7Kay8ofbbptva mdk9bSisbfAUEDoYRGV4hBadAG6gIVM5OJJv1dAwcunphNiou324DLqTAv.6zA3Tn0ozjSNM835e e8gqbdX1wNFr8PTDMpfwJoURKMiCqyL85C8rNrJ6jDftSsRiWQOwJb9n4TSNueiEgTV112AGSyAM nK5llCCl.7Zf5oIBzIt3D76aWqbBb83LdDL7zjQovzcBRBxM8VDdM5QX0lSxEWZcSfd2wxziR4ff AQ2W0UxKiTNLox2LZbSdon6IYVGFNZ4pbLLtaa3nx40buxq7QUXhNhQO.Aa2DfkwbwWMuWKxpIEe z3E.HUjNKmj7KhznM.pLdDnClhm78ZTiOyy_224dexCrM5lDekKHAKRKYOl3KEZ0IrDc74HisOqx QuqCyqHdPlZ.6WTVDL.Ol93txnNHH6fj6Cll0xvl_oiaLCLz0ekvfvXtMeUJ4Hd8LuJiNxSvXLVp Ty7MVKtQS8aWhzrauSW2vSUPoXpk.G9GGc0fX0bcYnw17zEqk3YFO2vQRvYBdiBkcikHBEYCWDWX FBWFl9_.D0l6KF4tz6GbXDwZtAnZGXhLo_1rmr_UB5uMtK8Y4VswICXzaKkPUKBXqoInVafhAFFB .gy3qU4vL5huYNdxsE5mRPABPlw0Z8Yd_u6rCs.ikHwtmoXD4X38zKDWPZQiCnfXI4LZJNqGJYHd fllgMpl2RzuJ0bOZvcS5g.O_QqIr_TfKFSqvQdCDbuclxQJe27TZzyiJOUcDVE6VWEUH3ibQBriz QWzGaqW7_V4KDlfzI1lZS9T4QdJfDKlqYUzSVYUViROYthDt9c3oisEPF6rWJAjhQjdV7oyqkmFv VrUcDoyHwDDmW26OiRikkWl2HHRuYa.8GFN8lX41gGFZQoFvQb_qAmg0kubKIpByWcKoqiQcVmsc vhwwVWAUz_M.52mNo7TRHXTx0fuPk9EOOde.MzEntg2p8hNGD9Szw2MIZUYiG7tAyxYgMDtkYTuQ jGGYBG1M9Nt2rkXxW4XRn2zMVEqdg_5LOjKZPQkoidfAXvM7ZI6mbdftLN66zyfFO1pg8OyxsJDS J5Zhfva6ZIMQOPO_eiwjMekJ9hLrZU2XJmHnaXBKXtcV7TOad2aelL9vkWxjhEScWsK.QdKm8fzh Slb8Y.CnYD_RPTeJ45fJCHEWeOpnjncm.01.7AXYZ7GXysMsTgZ_31eXb8aQeZPTgLs1DNrr.Ovy G6GzDqa8J481dc81ppqVClOqyCF5mtEJWAdVQvEYlQuJbnyQogfoCNFSyNM0Ej5cjNbGtenELmsu U41q8Dp_GlwMwRX7LcgtRd69KdvmcYXj3tVepz1Q1Yp6gjvzTBKNIJPYycTK82Bbb5lqTqrX7did QwrPfL7w5H35iYthszQ4FIZviXr7zFcSeSVfPV6ddybokHYeqDMIKYXkWxryEe_GZXBP4qU.MY1e QUCPWW_nqoctWYc5hStuL4I9nu7Etqs00kC5jF5lZKQ2VJN7UzVPXSsh9vxDu9pkt8c_ksu6xnF3 kzJI5WAewX0bJk0yqp9suR_YprwCmuoILBAnBi.qzhUKI9CiC8Tyf83bbcu4_VPmL6gH3_JdangF N9KYcY81Hi2ew7dloTw-- X-Sonic-MF: X-Sonic-ID: 0251c7dc-41c8-4f0a-b0fa-59220f13ad39 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Nov 2025 09:15:25 +0000 Received: by hermes--production-gq1-76c986f798-8dnv2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5290d0ea80a78a18d9330102fdb9be91; Mon, 17 Nov 2025 09:15:23 +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: <0157ECE7-759F-4C00-9656-CB2ECA65E19E@yahoo.com> Date: Mon, 17 Nov 2025 01:15:13 -0800 Cc: Warner Losh , bob prohaska , "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6F882958-E901-489B-A758-BCCFE5D01FBA@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> <0157ECE7-759F-4C00-9656-CB2ECA65E19E@yahoo.com> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.53 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.53)[-0.527]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4d92CM1p8Tz3lrt On Nov 17, 2025, at 00:24, Mark Millard wrote: > On Nov 16, 2025, at 13:11, Michal Meloun wrote: >=20 >> 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 >>=20 >> Unfortunately, that doesn't help. I'm out of ideas on how to debug = this, all of my attempts have failed. >>=20 >> 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. >>=20 >> I would be grateful for any help and ideas on what to do next. >> Michal >=20 > [Note: The context is an official pkgbase distribution context > and so the /usr/src/ is not tied to git. /usr/src-investigation/ > is a copy of /usr/src/ that was then modified. Also, this is > via a armv7 chroot on the aarch64 Windows Dev Kit 2023, not > via armv7-only hardware.] >=20 > The crude hack reported later below has shown the first failure > indicated as happening during base_alloc_edata by reporting: >=20 > p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x11u >=20 > as the failure message. >=20 >=20 > # diff -u /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h = /usr/src-investigation/contrib/jemalloc/include/jemalloc/ > --- /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h = 2025-11-12 02:24:28.000000000 -0800 > +++ = /usr/src-investigation/contrib/jemalloc/include/jemalloc/internal/ehooks.h= 2025-11-16 23:47:10.965711000 -0800 > @@ -1,6 +1,7 @@ > #ifndef JEMALLOC_INTERNAL_EHOOKS_H > #define JEMALLOC_INTERNAL_EHOOKS_H >=20 > +#include > #include "jemalloc/internal/atomic.h" > #include "jemalloc/internal/extent_mmap.h" >=20 > @@ -158,6 +159,7 @@ > * This isn't really ehooks-specific (i.e. anyone can check for zeroed = memory). > * But incorrect zero information indicates an ehook bug. > */ > +__attribute__ ((visibility ("internal"))) extern volatile = sig_atomic_t which_base_extent_context; // HACK FOR DEBUGGING USE > static inline void > ehooks_debug_zero_check(void *addr, size_t size) { > assert(((uintptr_t)addr & PAGE_MASK) =3D=3D 0); > @@ -167,7 +169,45 @@ > /* Check the whole first page. */ > size_t *p =3D (size_t *)addr; > for (size_t i =3D 0; i < PAGE / sizeof(size_t); i++) { > - assert(p[i] =3D=3D 0); > +switch (which_base_extent_context) > +{ > +case 0x10u: // base_alloc > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x10u); > + which_base_extent_context=3D 0x0u; > + break; > +case 0x11u: // base_alloc_edata > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x11u); > + which_base_extent_context=3D 0x0u; > + break; > +case 0x12u: // base_new > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x12u); > + which_base_extent_context=3D 0x0u; > + break; > +case 0x13u: // base_boot > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x13u); > + which_base_extent_context=3D 0x0u; > + break; > +case 0x20u: // extent_commit_wrapper > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x20u); > + which_base_extent_context=3D 0x0u; > + break; > +case 0x21u: // extent_commit_zero > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x21u); > + which_base_extent_context=3D 0x0u; > + break; > +case 0x22u: // ecache_alloc_grow > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x22u); > + which_base_extent_context=3D 0x0u; > + break; > +case 0x00u: // None known > + assert(p[i] =3D=3D 0 && which_base_extent_context =3D=3D 0x00u); > + which_base_extent_context=3D 0x0u; > + break; > +default: // Some other context > + assert(p[i] =3D=3D 0 && which_base_extent_context !=3D 0x00u); > + which_base_extent_context=3D 0x0u; > +} > + //assert(p[i] =3D=3D 0); > } > /* > * And 4 spots within. There's a tradeoff here; the larger >=20 >=20 > # diff -u /usr/src/contrib/jemalloc/src/base.c = /usr/src-investigation/contrib/jemalloc/src/base.c > --- /usr/src/contrib/jemalloc/src/base.c 2025-11-12 02:24:28.000000000 = -0800 > +++ /usr/src-investigation/contrib/jemalloc/src/base.c 2025-11-16 = 23:50:14.396483000 -0800 > @@ -1,3 +1,4 @@ > +#include > #include "jemalloc/internal/jemalloc_preamble.h" > #include "jemalloc/internal/jemalloc_internal_includes.h" >=20 > @@ -340,12 +341,15 @@ > b0get(void) { > return b0; > } > + > +__attribute__ ((visibility ("internal"))) volatile sig_atomic_t = which_base_extent_context=3D0x0u; // HACK FOR DEBUGGING USE >=20 > base_t * > base_new(tsdn_t *tsdn, unsigned ind, const extent_hooks_t = *extent_hooks, > bool metadata_use_hooks) { > pszind_t pind_last =3D 0; > size_t extent_sn_next =3D 0; > +which_base_extent_context=3D 0x12u; >=20 > /* > * The base will contain the ehooks eventually, but it itself is > @@ -476,12 +480,14 @@ > */ > void * > base_alloc(tsdn_t *tsdn, base_t *base, size_t size, size_t alignment) = { > +which_base_extent_context=3D 0x10u; > return base_alloc_impl(tsdn, base, size, alignment, NULL); > } >=20 > edata_t * > base_alloc_edata(tsdn_t *tsdn, base_t *base) { > size_t esn; > +which_base_extent_context=3D 0x11u; > edata_t *edata =3D base_alloc_impl(tsdn, base, sizeof(edata_t), > EDATA_ALIGNMENT, &esn); > if (edata =3D=3D NULL) { > @@ -523,6 +529,7 @@ >=20 > bool > base_boot(tsdn_t *tsdn) { > +which_base_extent_context=3D 0x13u; > b0 =3D base_new(tsdn, 0, (extent_hooks_t = *)&ehooks_default_extent_hooks, > /* metadata_use_hooks */ true); > return (b0 =3D=3D NULL); >=20 >=20 > # diff -u /usr/src/contrib/jemalloc/src/extent.c = /usr/src-investigation/contrib/jemalloc/src/extent.c > --- /usr/src/contrib/jemalloc/src/extent.c 2025-11-12 = 02:24:28.000000000 -0800 > +++ /usr/src-investigation/contrib/jemalloc/src/extent.c 2025-11-16 = 23:49:55.820658000 -0800 > @@ -1,3 +1,4 @@ > +#include > #include "jemalloc/internal/jemalloc_preamble.h" > #include "jemalloc/internal/jemalloc_internal_includes.h" >=20 > @@ -90,11 +91,14 @@ > assert(edata =3D=3D NULL || edata_guarded_get(edata) =3D=3D guarded); > return edata; > } > + > +__attribute__ ((visibility ("internal"))) extern volatile = sig_atomic_t which_base_extent_context; // HACK FOR DEBUGGING USE >=20 > edata_t * > ecache_alloc_grow(tsdn_t *tsdn, pac_t *pac, ehooks_t *ehooks, ecache_t = *ecache, > edata_t *expand_edata, size_t size, size_t alignment, bool zero, > bool guarded) { > +which_base_extent_context=3D 0x22u; > assert(size !=3D 0); > assert(alignment !=3D 0); > witness_assert_depth_to_rank(tsdn_witness_tsdp_get(tsdn), > @@ -1114,6 +1118,7 @@ > bool > extent_commit_wrapper(tsdn_t *tsdn, ehooks_t *ehooks, edata_t *edata, > size_t offset, size_t length) { > +which_base_extent_context=3D 0x20u; > return extent_commit_impl(tsdn, ehooks, edata, offset, length, > /* growing_retained */ false); > } > @@ -1297,6 +1302,7 @@ > bool > extent_commit_zero(tsdn_t *tsdn, ehooks_t *ehooks, edata_t *edata, > bool commit, bool zero, bool growing_retained) { > +which_base_extent_context=3D 0x21u; > witness_assert_depth_to_rank(tsdn_witness_tsdp_get(tsdn), > WITNESS_RANK_CORE, growing_retained ? 1 : 0); Well, with this hack, the behavior looks to have changed to always fail leading-to an initial: *** [libzpool.so.2.full] Error code 1 The hack may disturb things too much and may not be sufficiently close to valid code for the context. Using -j1 got a first failure message: Failed assertion: p[i] =3D=3D 0 && which_base_extent_context =3D=3D = 0x22u That would be during ecache_alloc_grow. Still: *** [libzpool.so.2.full] Error code 1 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Nov 17 09:31:54 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 4d92ZS1c26z6GwqK; Mon, 17 Nov 2025 09:32:00 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d92ZR15lwz3nYc; Mon, 17 Nov 2025 09:31:59 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=MrnMUnHh; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=cOBawZO9; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.151 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id 35CC6EC006C; Mon, 17 Nov 2025 04:31:57 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Mon, 17 Nov 2025 04:31:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763371917; x=1763458317; bh=B5nIGIvyMJ VG80QpRKFAf2HG30Fxjrk1AYGqAHuYIrM=; b=MrnMUnHhsbdMVMVFQYsOOiyiDq hcJoxb36v6cAl2yDDHrpAb8YhUtv8lCxfWGbN/f4hwqUlHODPe1v6vaULjre+/d6 7w7qgg4QXF4j4C4IFZfPGXZVnndtnvE6rdS6lIKfiQpf6CFIEMCMRSNc0xHme6Sr i8olwYgfeRRhaAhJ/DQGpcX+SEt57JWRo/33J1et6zIqKU+q6lK8kNZqEmImj4/8 EiYMW7fWbcbgRSQEPnzAojohgY/76TYRtbTMIfLJMq/iizoObbNnKRHp7uY2ZMcO aFhJSvyh3qSCKBRZyk4sPkURCmShagZQbsTPDGOQWsYtVnheXV7eN9JrnVcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763371917; x=1763458317; bh=B5nIGIvyMJVG80QpRKFAf2HG30Fxjrk1AYG qAHuYIrM=; b=cOBawZO9U1XpORTLOAZg++RTaoVUp0RqJPy2uwFC2uu8PyBVUCV +Yr2Kl/Y7X9eXnjzAX498VTecKCraFBevRVlJ+VQoNET4eVHM7pvsqOo3EzHgPn2 xwW5cJcQHASS/zxju+u4vp9oXWohUKmwUzTPlSXlX8Ts+KgR1tr/W2E45aXYlSQe 3RvEsxUt+mrihgYuvBse0OYmhfzDBYne6/ZIXpnM4utMkgSueEOGT/7xtwetrqZH T0HNVU3/ww7s4dOfCIAmoEK1D8tvQViQLi6drPtGe+0XZmpcWDeGSRg5/9ismsk5 YnG99FQx8PJqpTjigkDGNUfRsDxjeY0phYw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvudekudduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtrodttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepieevgfefgeffhffggfeitdejjefhteeffefgleefieevleevjeeuiedugeelgf fgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqrghrmhesfhhrvggvsghsugdrohhrghdprhgtphht thhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Nov 2025 04:31:56 -0500 (EST) Date: Mon, 17 Nov 2025 09:31:54 +0000 From: void To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: WITHOUT_CLEAN confusion in -current Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.71 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; NEURAL_HAM_SHORT(-0.11)[-0.108]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.151:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4d92ZR15lwz3nYc On Sun, Nov 16, 2025 at 11:29:07PM -0700, Warner Losh wrote: >As others have pointed out, this is almost certainly because you're missing >a "=y". > >You can keep using -DNOCLEAN, at least for as long as the warning is there. >IT's what I use, though WITHOUT_CLEAN=y is the default these days. > >Warner DOH sorry everyone I should have seen that. "my bad". Indeed i did miss off the "=" whoops -- From nobody Mon Nov 17 15:38:09 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 4d9Bgl5bl9z6GRXN; Mon, 17 Nov 2025 15:37:07 +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 4d9Bgj1gR2z3K36; Mon, 17 Nov 2025 15:37:05 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AHFcA7O053467 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 17 Nov 2025 07:38:10 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AHFc9tI053466; Mon, 17 Nov 2025 07:38:09 -0800 (PST) (envelope-from fbsd) Date: Mon, 17 Nov 2025 07:38:09 -0800 From: bob prohaska To: Carl Shapiro Cc: Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.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: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.04 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; NEURAL_HAM_SHORT(-0.95)[-0.946]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4d9Bgj1gR2z3K36 On Fri, Nov 14, 2025 at 05:04:10PM -0500, Carl Shapiro wrote: > bob prohaska writes: > > > Those files have been overwritten by restarting the buildworld sessions. > > They tend to be large and diffcult to synchronize with the .cpp and .sh > > files generated by the crash. It could be done if it's useful. > > At least from the perspective of debugging malloc(3), they'd be useful, > even if the files for reproducing the crash are not synchronized with > the std{err,out} output. For example, there might be other log messages > generated by jemalloc. > > I need a moment to look at the code and step through what it is doing on > FreeBSD but my first guess is that there might just be an incorrect > assumption about committed memory always coming back zeroed. That > should be true on 64-bit Linux when MADV_DONTNEED is used but not true > if another advice is used like MADV_FREE on either FreeBSD or Linux. It > is always possible that the kernel is mishanding some memory but I would > like to rule out jemalloc itself before pointing a finger there. Here is an example of both the buildworld.log file and the generated diagnostic files, which for some reason didn't include .sh and .cpp files. http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/buildworld.log http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbolizer-input-bcaebf http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbolizer-output-1aa401 This host's particular buildworld attempt has been going on for a long time, to the extent that world and kernel are mismatched: root@www:/usr/src # uname -KU 1600000 1500063 The immediate goal is to get them back in sync. Thanks for reading, bob prohaska From nobody Mon Nov 17 18:51:37 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 4d9H0G3YPqz6GlSJ; Mon, 17 Nov 2025 18:51:42 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-24425.protonmail.ch (mail-24425.protonmail.ch [109.224.244.25]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9H0G05kJz40VF; Mon, 17 Nov 2025 18:51:42 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1763405499; x=1763664699; bh=epVBIJBzuSumPRX5d0WQwkODYEWngUiuOoH8xt4BrlY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=nTwtBR7ebb7INNeMCrU74bmw3tzLbGe2ZOC7PDCyCkwq07nRfxvV+9RHrW8Dx6IsV CFbEKlFGBSoRZgAN3J5DWb8kxguu3WTvrizV2jBnrmhH4AhxZIn8cPqbKBSsUAvKIr KKqszrseg0UfedEe7eDS9kM732B4dllmErNXNCj12ke6z4CNmPIrWc4gySTKf+7evz A+FpwK8akeeAHyRQBi9B9Oc5Ju0Mi1z5eVzr63wmmNzQwKek2FqUuN7+SGrRigwRhe 1JcK/NyBXH3Ww8rajhrdVkxjXwHbeL8OoRwNwEkeCy+lgDB6PFmzQJylCKHoDyZq0T sIsyxnm9BxGYQ== Date: Mon, 17 Nov 2025 18:51:37 +0000 To: Mark Millard From: Minsoo Choo Cc: FreeBSD Current , FreeBSD-STABLE Mailing List , FreeBSD-pkgbase@freebsd.org Subject: Re: 15.0's and main's [so: 16's] jemalloc man page reports "This manual describes jemalloc 5.2.1-0-gea6b3. . ." but 5.3.0-0-g54eae is in use instead for 15.0+ and main 16. Message-ID: In-Reply-To: <6C625281-B892-43AF-AD87-87950556EE02@yahoo.com> References: <6C625281-B892-43AF-AD87-87950556EE02.ref@yahoo.com> <6C625281-B892-43AF-AD87-87950556EE02@yahoo.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 7647386f2d48a36b642f525524809ba3e56ef6a7 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d9H0G05kJz40VF Hi Mark, Thank you for reporting this issue. The pull request for addressing this issue has been created at https://gith= ub.com/freebsd/freebsd-src/pull/1890. On Sunday, November 16th, 2025 at 4:34 PM, Mark Millard = wrote: > . . . > LIBRARY > This manual describes jemalloc > 5.2.1-0-gea6b3e973b477b8061e0076bb257dbd7f3faa756. More information can > be found at the jemalloc website[1]. > . . . > > https://jemalloc.net/jemalloc.3.html reports: > > LIBRARY > This manual describes jemalloc 5.3.0-0-g54eaed1d8b56b1aa528be3bdd1877e59c= 56fa90c. More information can be found at the jemalloc website. > > https://cgit.freebsd.org/src/commit/contrib/jemalloc?id=3Dc43cad87172039c= cf38172129c79755ea79e6102 > > has text: --with-version=3D5.3.0-0-g54eaed1d8b56b1aa528be3bdd1877e59c56fa= 90c > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Tue Nov 18 01:09:21 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 4d9RMp4hcsz6HJQG for ; Tue, 18 Nov 2025 01:09:10 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4d9RMn3Jy4z3DTG for ; Tue, 18 Nov 2025 01:09:09 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=tarsnap.com; spf=pass (mx1.freebsd.org: domain of gperciva@tarsnap.com designates 54.86.246.204 as permitted sender) smtp.mailfrom=gperciva@tarsnap.com Received: (qmail 75291 invoked from network); 18 Nov 2025 01:09:08 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 18 Nov 2025 01:09:08 -0000 Date: Mon, 17 Nov 2025 17:09:21 -0800 From: Graham Percival To: freebsd-current@freebsd.org, freebsd-git-weekly@tarsnap.com Cc: Colin Percival Subject: FreeBSD Git Weekly 2025-11-10 to 2025-11-16 Message-ID: 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 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.61 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.97)[-0.969]; NEURAL_HAM_SHORT(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; R_SPF_ALLOW(-0.20)[+ip4:54.86.246.204/32]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4d9RMn3Jy4z3DTG Hi all, I'm happy to announce FreeBSD git weekly for 2025-11-10 -- 2025-11-16: https://freebsd-git-weekly.tarsnap.net/2025-11-10.html It's a list of the 181 commits in that week, split into categories. Highlighted commits: - libpam: Move to a new "pam" package - lib/libc: implement C23 memalignment() - RELNOTES: Document FreeBSD-base pkg .conf shuffle "Highlighted" commits are selected automatically if a commit modifies UPDATING, or if the commit message contains a "Relnotes:" line. If you think that another commit should be highlighted, let me know and I'm happy to make it so. To see all reports: https://freebsd-git-weekly.tarsnap.net/ This work is funded by cperciva@ and Tarsnap Backup Inc. Cheers, - Graham Percival From nobody Tue Nov 18 03:53: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 4d9W1M6f6Fz6HXGd for ; Tue, 18 Nov 2025 03:53:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9W1M4bTCz3cm1 for ; Tue, 18 Nov 2025 03:53:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-8b2d7c38352so290076985a.0 for ; Mon, 17 Nov 2025 19:53:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763438007; x=1764042807; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oOCUHE2UQZOftq87SR8oQc4EoLBCf6OCK0H0WBAGzCw=; b=srNrMldjtxTBkcZt3vMc8mKIRKFdMbiPYp/KlQId8+QfHoEVrmb/Hyt4QxafpWDCZd 69dH4X2evS6K5MkbHS3dkJ8YC4bEfrqJdowfPi9QlF009o54G8d+c/eNapNK/3sbfoky YeZxyXF8Z/KANMuSULQ85nckhcPw7Ex5jGDBnlCDxcy2S+mrt9uDBDVTsT9+ytud09s9 3b49FCWM6aoCZnIYd7UN5j2n7/yn9LTRaRwqxg6HvBkS77CUh7qPyhGGn9qvMWW2xkTC XpRfPVoyXZobAw1cyjreXeWyg9EN2lAydINqeSiBk6xdw9gPyDDWflO4Salt01cqjbV0 5T9A== X-Forwarded-Encrypted: i=1; AJvYcCVUpQuzDSyE1XA5Ab8p7/8S+iACZsgVVMXq2coEWfDdm/qbhZi+BSJjLxD8PA+k0BCWp/SW80w2YDeYbnED6EU=@freebsd.org X-Gm-Message-State: AOJu0YwiFMQ1qDx5tCZ7fNXHpfyH81I3VxFE7ZpyewPrHAsOCkai79lT DXPR37f/ZGLv2gUl8FOVFwNcSQ3rtDmT8axqm99C50onb1RuQTcUju5tADSFJbaR9f7nwW42bMW V58VV1T1HsGbgyhpQL7JFSXQ6sTzQ0wQ= X-Gm-Gg: ASbGncs/BQO3QT2bDAjxisjq+BGsIHSe1yPIXijD6FeFfwUlNVK8lgjjeChxGlrh846 CSUjXIcRwkEATBsSOcLsEE2rN9hW6tX7YA4vcdEUdiHl2jRV21zNkt3ufWN0Zgo0GyaEInuxYXf JrTzZP3UcmgqgZDIHGE2/5VXf7uRA83L/gyjpK4f3UXqQ3xPusfFvPe99Db582LZaoW7PT3BlZ/ E0Oo/+EdrjvM8jdXqi+V6c3QEGeQbUaNs3+gy+mCt7R4kpnUA2rO/f0V8sL1sCa4zMoU1kBCetq 1Eg2kaEhMmMy89QQzRXgTLlOBRLdPQ== X-Google-Smtp-Source: AGHT+IGKUCFz32fZiFoHOej8PtQWsXfF4auj2BtrL1eo8Ohj/VHqS403j4a0+yXivHVjGUe9HwdMAYfDUxgsAQAvS7M= X-Received: by 2002:a05:620a:4107:b0:8b2:faa3:5639 with SMTP id af79cd13be357-8b300ebdad5mr245478285a.11.1763438006810; Mon, 17 Nov 2025 19:53:26 -0800 (PST) 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 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> In-Reply-To: From: Adrian Chadd Date: Mon, 17 Nov 2025 19:53:15 -0800 X-Gm-Features: AWmQ_bnqCQiNy-acpdPb8rrxjp2JCyRLn4Bve1EKxe8kEQffzdKAKr9SE0KZ84M Message-ID: Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: bob prohaska Cc: Carl Shapiro , Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fabcd00643d667eb" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d9W1M4bTCz3cm1 --000000000000fabcd00643d667eb Content-Type: text/plain; charset="UTF-8" (random reply, sorry bob) i think i saw someone say they can trigger it with a single super large source file, is that right? No need for parallelism, just build that one file? If so please pipe up, i'd like to see if you can get that over to mark on his armv8 box and then we can try some stuff (like using cpuset to pin the compilation to a single core so it doesn't migrate) -adrian On Mon, 17 Nov 2025 at 07:37, bob prohaska wrote: > On Fri, Nov 14, 2025 at 05:04:10PM -0500, Carl Shapiro wrote: > > bob prohaska writes: > > > > > Those files have been overwritten by restarting the buildworld > sessions. > > > They tend to be large and diffcult to synchronize with the .cpp and .sh > > > files generated by the crash. It could be done if it's useful. > > > > At least from the perspective of debugging malloc(3), they'd be useful, > > even if the files for reproducing the crash are not synchronized with > > the std{err,out} output. For example, there might be other log messages > > generated by jemalloc. > > > > I need a moment to look at the code and step through what it is doing on > > FreeBSD but my first guess is that there might just be an incorrect > > assumption about committed memory always coming back zeroed. That > > should be true on 64-bit Linux when MADV_DONTNEED is used but not true > > if another advice is used like MADV_FREE on either FreeBSD or Linux. It > > is always possible that the kernel is mishanding some memory but I would > > like to rule out jemalloc itself before pointing a finger there. > > Here is an example of both the buildworld.log file and the generated > diagnostic files, which for some reason didn't include .sh and .cpp files. > > > http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/buildworld.log > > http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbolizer-input-bcaebf > > http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbolizer-output-1aa401 > > This host's particular buildworld attempt has been going on for a long > time, to the extent that > world and kernel are mismatched: > root@www:/usr/src # uname -KU > 1600000 1500063 > The immediate goal is to get them back in sync. > > Thanks for reading, > > bob prohaska > > > --000000000000fabcd00643d667eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(random reply, sorry bob)

i = think i saw someone say they can trigger it with a single super large sourc= e file, is that right? No need for parallelism, just build that one file?

If so please=C2=A0pipe up, i'd like to see if y= ou can get that over to mark on his armv8 box and then we can try some stuf= f (like using cpuset to pin the compilation to a single core so it doesn= 9;t migrate)


-adrian

=

On Mon, 17 Nov 2025 at 07:37, bob prohaska &l= t;fbsd@www.zefox.net> wrote:
On Fri, Nov 14, 2= 025 at 05:04:10PM -0500, Carl Shapiro wrote:
> bob prohaska <fbsd@www.zefox.net> writes:
>
> > Those files have been overwritten by restarting the buildworld se= ssions.
> > They tend to be large and diffcult to synchronize with the .cpp a= nd .sh
> > files generated by the crash. It could be done if it's useful= .
>
> At least from the perspective of debugging malloc(3), they'd be us= eful,
> even if the files for reproducing the crash are not synchronized with<= br> > the std{err,out} output.=C2=A0 For example, there might be other log m= essages
> generated by jemalloc.
>
> I need a moment to look at the code and step through what it is doing = on
> FreeBSD but my first guess is that there might just be an incorrect > assumption about committed memory always coming back zeroed.=C2=A0 Tha= t
> should be true on 64-bit Linux when MADV_DONTNEED is used but not true=
> if another advice is used like MADV_FREE on either FreeBSD or Linux.= =C2=A0 It
> is always possible that the kernel is mishanding some memory but I wou= ld
> like to rule out jemalloc itself before pointing a finger there.

Here is an example of both the buildworld.log file and the generated
diagnostic files, which for some reason didn't include .sh and .cpp fil= es.

http://www.zefox.n= et/~fbsd/assertion_failure/hostname_www.zefox.org/buildworld.log
http://ww= w.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbolizer-input= -bcaebf
http://w= ww.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbolizer-outp= ut-1aa401

This host's particular buildworld attempt has been going on for a long = time, to the extent that
world and kernel are mismatched:
root@www:/usr/src # uname -KU
1600000 1500063
The immediate goal is to get them back in sync.

Thanks for reading,

bob prohaska


--000000000000fabcd00643d667eb-- From nobody Tue Nov 18 04:51:37 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 4d9XJs1Zkjz6GN7Y for ; Tue, 18 Nov 2025 04:51:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9XJr1PVkz3kD1 for ; Tue, 18 Nov 2025 04:51:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=TRxHyNgH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::630) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-298145fe27eso67697665ad.1 for ; Mon, 17 Nov 2025 20:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1763441509; x=1764046309; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=EHZ/ICgOxhhMF4ALK68KpCcYx2C8fFgISbtrpURYVWI=; b=TRxHyNgHz1cGenJ9QJho+KyYvSRq7lhmgOlJ0zkZyLzRSWHrsRJ0feNcLlNGwqqfs+ lO0UONmkfhQj/ekfzXXPvqG7bFiSfYz+Pk2bGxr+f44o+GFMf9WdLbK43rjAYPS2/0ll xqAmq6FePAjkurf2KhZX9eVkNmQF4UeugqginKU70xkR3uA6FYVnqI42coTp6lvszNJF Hi3X9QYZ2lFzz9VxJkYEjVhIsGBJUUzf0VElP1lpJDGRKcj1+KNyVCpddeau8JBfIfmn QSPWE8lXYwqwknIFXvt8Aw4qkg771+h7Po46MU4R0006yQNHH6DKM40gSz7lzEtSBpix cpVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763441509; x=1764046309; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EHZ/ICgOxhhMF4ALK68KpCcYx2C8fFgISbtrpURYVWI=; b=ibaU5oxuFby4iCBtx+C5pl19QmA1LJuPxy0R4491rTY4m5jt+SffCU98TZMw+5z8Hz P5z3sH5YP8oeJBg4zsTV4C1SQsbI9XZpVlbih27DmTE7+Vm6vGVnOtSK08dTfRqEYjZB eHfWeMl9pK2nlsEK0l3FDH5qGDQricvt+rOc1Iwx37hkcC+5LWUefGXfPHAwsSzfj80m VGGblKxPqNn1px0C7plWE9GrQAv83o/M9HILzlxL8g7MiWgWW+OIRGdUY/fkC8PMUckg 7ooD6DyZ+ahSsh7OAn8+nNKUomoPGSopYVGC97R66S2AS9L/uOMkHfzRkmbPz9EpGszd eMEg== X-Gm-Message-State: AOJu0YxB6S5aEnUc9TWrw+fb6iyyjUgRKMEYAl9avmZbgtKw7ymWbNdo TkSw3LO94R703XOyjkGdgqVY5jrdRupfLPOmNTuwmXcLgSrjcqYIWTuT6dWaKW8/GRDgtsIqXLa DA/sEIFrGBLtULJcWGxSxuq8JdlRY4yijV5ItLjicD4sSmDdvRWmlppQ= X-Gm-Gg: ASbGncs1vzBD4MMuvDcnkP4MuYWkWuYtZlFZyzNULdNdaaduO8p3/OlDnZWHOrL9nMu Wqgjj+rt02PZS9dYYOodqg8AwEDihz4Z2fGWMjiXtiaB3W97CG8rFyQtW0ilkx8XkIyWa5B76vb zHWx/Wwhemf3gD+XM6xSJIanydM7nwPmTZzcZoWE+jnOqFMrRSCC0/0WZHlxJCuInIJdqXYmMk4 O0MmudyOizlkhKEeCv+buDq27rR28VoNFmQlVc0FBFbid8Wuhwiiy0XEIUMJw1GL0DQGRs= X-Google-Smtp-Source: AGHT+IHCQUVk0gstNE6wdlEzTZjfDx+NRiNaA2l0quwHshfP6nfraMDcC3IJpP2uP+8yOs6pxQlO0qYkbEn2kyVRbB0= X-Received: by 2002:a17:903:2b10:b0:297:d777:a2d4 with SMTP id d9443c01a7336-2986a752800mr172554445ad.46.1763441508635; Mon, 17 Nov 2025 20:51:48 -0800 (PST) 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 References: <202511180445.5AI4jnYK085911@gitrepo.freebsd.org> In-Reply-To: <202511180445.5AI4jnYK085911@gitrepo.freebsd.org> From: Warner Losh Date: Mon, 17 Nov 2025 21:51:37 -0700 X-Gm-Features: AWmQ_bnvchPQyxeox6hlTpXtATNqUsTrbldq0lHF2N-paPUx-psuWqb55z7n-fA Message-ID: Subject: Fwd: git: 396b32e801d6 - main - stand: Add back missing EFIAPI define To: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000b460cd0643d738e4" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::630:from]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4d9XJr1PVkz3kD1 --000000000000b460cd0643d738e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Normally I don't forward things like this to -current (It's current after all), but I broke at least the amd64 efi boot loader yesterday and this is the fix for it. My apologies for anybody that got stuck. Warner ---------- Forwarded message --------- From: Warner Losh Date: Mon, Nov 17, 2025 at 9:45=E2=80=AFPM Subject: git: 396b32e801d6 - main - stand: Add back missing EFIAPI define To: , , < dev-commits-src-main@freebsd.org> The branch main has been updated by imp: URL: https://cgit.FreeBSD.org/src/commit/?id=3D396b32e801d615954750162a616b4e917= 4b39916 commit 396b32e801d615954750162a616b4e9174b39916 Author: Warner Losh AuthorDate: 2025-11-18 04:44:07 +0000 Commit: Warner Losh CommitDate: 2025-11-18 04:45:59 +0000 stand: Add back missing EFIAPI define EFIAPI has to be defined correctly for amd64, or things won't boot because it uses a different API than we normally use. Normally, this only affects amd64, since all the other archs are basically nothing. Tested on: amd64, aarch64 and armv7 (the frist two by markj and I with differnet test setups). Fixes: 43b8edb32051 Sponsored by: Netflix Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53799 --- sys/sys/efi-edk2.h | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/sys/sys/efi-edk2.h b/sys/sys/efi-edk2.h index 513c56549803..b27b26bd613c 100644 --- a/sys/sys/efi-edk2.h +++ b/sys/sys/efi-edk2.h @@ -41,7 +41,20 @@ typedef void VOID; /* We can't actually call this stuff, so snip out API syntactic sugar */ #define INTERFACE_DECL(x) struct x +#ifdef _STANDALONE +#if defined(__amd64__) +#define EFIAPI __attribute__((ms_abi)) +#endif +#ifndef EFIAPI // Forces EFI calling conventions reguardless of compiler options + #ifdef _MSC_EXTENSIONS + #define EFIAPI __cdecl // Force C calling convention for Microsoft C compiler + #else + #define EFIAPI // Substitute expresion to force C calling convention + #endif +#endif +#else #define EFIAPI +#endif #define IN #define OUT #define CONST const @@ -64,11 +77,13 @@ typedef void VOID; #define PACKED /* - * Since we're not compiling for the UEFI boot time (which use ms abi - * conventions), tell EDK2 to define VA_START correctly. For the boot - * loader, this likely needs to be different. + * For userland and the kernel, we're not compiling for the UEFI boot time + * (which use ms abi conventions on amd64), tell EDK2 to define VA_START + * correctly. For the boot loader, we can't do that, so don't. */ +#ifndef _STANDALONE #define NO_MSABI_VA_FUNCS 1 +#endif /* * Finally, we need to define the processor we are in EDK2 terms. --000000000000b460cd0643d738e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Normally I don't forward things like this to -current = (It's current after all), but I broke at least the amd64 efi boot loade= r yesterday and this is the fix for it. My apologies for anybody that got s= tuck.

Warner

---------- F= orwarded message ---------
From: Warner Losh <imp@freebsd.org>
Date: Mon, Nov 17, 2025 at = 9:45=E2=80=AFPM
Subject: git: 396b32e801d6 - main - stand: Add back miss= ing EFIAPI define
To: <src-committers@freebsd.org>, <dev-commits-src-all@freebsd.org>, <dev-commits-src-main@freebsd.org<= /a>>


The branch main has been updated by imp:

URL: https://cgit.= FreeBSD.org/src/commit/?id=3D396b32e801d615954750162a616b4e9174b39916
commit 396b32e801d615954750162a616b4e9174b39916
Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
AuthorDate: 2025-11-18 04:44:07 +0000
Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
CommitDate: 2025-11-18 04:45:59 +0000

=C2=A0 =C2=A0 stand: Add back missing EFIAPI define

=C2=A0 =C2=A0 EFIAPI has to be defined correctly for amd64, or things won&#= 39;t boot
=C2=A0 =C2=A0 because it uses a different API than we normally use. Normall= y, this
=C2=A0 =C2=A0 only affects amd64, since all the other archs are basically n= othing.
=C2=A0 =C2=A0 Tested on: amd64, aarch64 and armv7 (the frist two by markj a= nd I with
=C2=A0 =C2=A0 differnet test setups).

=C2=A0 =C2=A0 Fixes:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 43b8edb32051
=C2=A0 =C2=A0 Sponsored by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Netflix=
=C2=A0 =C2=A0 Reviewed by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 markj =C2=A0 =C2=A0 Differential Revision:=C2=A0 https://reviews.freebsd= .org/D53799
---
=C2=A0sys/sys/efi-edk2.h | 21 ++++++++++++++++++---
=C2=A01 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/sys/sys/efi-edk2.h b/sys/sys/efi-edk2.h
index 513c56549803..b27b26bd613c 100644
--- a/sys/sys/efi-edk2.h
+++ b/sys/sys/efi-edk2.h
@@ -41,7 +41,20 @@ typedef void VOID;

=C2=A0/* We can't actually call this stuff, so snip out API syntactic s= ugar */
=C2=A0#define INTERFACE_DECL(x) struct x
+#ifdef _STANDALONE
+#if defined(__amd64__)
+#define EFIAPI=C2=A0 =C2=A0 __attribute__((ms_abi))
+#endif
+#ifndef EFIAPI=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // Forces EFI calling conventions reguardless of compiler options
+=C2=A0 =C2=A0 #ifdef _MSC_EXTENSIONS
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 #define EFIAPI __cdecl=C2=A0 // Force C callin= g convention for Microsoft C compiler
+=C2=A0 =C2=A0 #else
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 #define EFIAPI=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // Substitute expresion to force C calling convention
+=C2=A0 =C2=A0 #endif
+#endif
+#else
=C2=A0#define EFIAPI
+#endif
=C2=A0#define IN
=C2=A0#define OUT
=C2=A0#define CONST const
@@ -64,11 +77,13 @@ typedef void VOID;
=C2=A0#define PACKED

=C2=A0/*
- * Since we're not compiling for the UEFI boot time (which use ms abi<= br> - * conventions), tell EDK2 to define VA_START correctly. For the boot
- * loader, this likely needs to be different.
+ * For userland and the kernel, we're not compiling for the UEFI boot = time
+ * (which use ms abi conventions on amd64), tell EDK2 to define VA_START + * correctly. For the boot loader, we can't do that, so don't.
=C2=A0 */
+#ifndef _STANDALONE
=C2=A0#define NO_MSABI_VA_FUNCS 1
+#endif

=C2=A0/*
=C2=A0 * Finally, we need to define the processor we are in EDK2 terms.

--000000000000b460cd0643d738e4-- From nobody Tue Nov 18 05:08:29 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 4d9XhM4MZVz6GP0K for ; Tue, 18 Nov 2025 05:08:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 4d9XhM124qz3mRX for ; Tue, 18 Nov 2025 05:08:50 +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=1763442523; bh=iifieztW7uRHqH8oyskZt5DiPMHmHlVyvz+P7Wt2Hqc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ks1Tx/hljPmuNPo27U1tNIRZwWj3tsfrQp0bZsfJ1NRbiBJ0YChHCzrFgGe5QCCL+bfN0J5xutRJZozmoUliCoHvDqfI70pN72KRhVMrS1q9BrBBclzaqugsd2WI0UVeY1priFNMTFTaatv3ORTDw29+lsz9rj9UKtCXbcgw3AXdG/W9zELFCjOlAcNIUsvTeoIVryopx/J5G6+IfUMlqW0gVeADineR0JmmJyBfp0USxVOFOTOKsg4+ljXgp675Bb27rSI1YowML3yVsL/Yn7P5+TgwfXN42CCwD6coAiUFGsDPFtDLJhoJKR4qQblJKbIRU2ZAjmvo201IaDH6dg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763442523; bh=1RX25GquqQ/okwzUvTCOlCQbEXUz9cf8S9AlgWF/ssa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qdr0l+U9sjC/X31NBJ1F1NYNOKIUlv+psbS7dwrZWnscNxIhRcy6zaomw/PvW8mQZ9WqOwVIiw1UBGAVN+VFiLptcgMJXumm7U1z4VegrPdOtcWRVGlp/mQGgcHRJbZMocD1DxSS12OmMYWWzfckHwSyMHn3pq39R9V6KZfFyB2vle3AyPqwEc6jpArNaLHA1teeiLMTkoMbPl3pgMNt/qNZZhAx2uQkRsZfCm4mHacEznAd48FnGDcwiTzIlKOVC9vDenHe2YUYXtiXPoOPyUKR41sGaPrzfyPANUBT9Ex9uSo/kONBVJyeIoAoheWEdvGmTsWcnsZKqvDwHmAkRQ== X-YMail-OSG: YWqp7bUVM1lKm4OSBNJ0_Zv5AN8jMR3hXZCprlLr6UDJD.DYyZM6TNjM5GkK262 VlRDjwALZcEo.dKTl8C6lw3.HS8JY1iSm9OS2Y7K6HDtv0RTOVL4_b8CYlmCqeY_8gih644TfHVH C9TrHfV4FZxYKjL6aCVfMzE5A.Bwlmozqc_DP14Tuy0Y6avKbYFs6FHYipC0G2CBnQi3A0bAs4jP TSP6G53XyBdqdz8FsqmFLSP2FEYSHS69LnqLJQzTMyuNpurwN7RMBd8u6fyMlO59KJTVVL4EwPAY 0hM7MgDwMGbUmkMM.YscAHeaSzBEeUKf_qth_2pY96sNYyj4d8i7Owc0EBxzDNrfW2v_PEz2SjUX R9gr1X7_eOaUn9xi4AgrLaa63enJETBuCcQaEGYEWQHroXEeMXkKLiefsbrpJ6nGwJ2PGYDXnmDs l7lrnEBvn3Vwdi6JPABgOE7TqJuBXz_F17Mj_FRo9DherrcsNXOCX9DgqOcjQSxaNguDgk9kuoZ6 XvXTXWJ_7n9U9F45gkNXPTH13D6h8nai4XMaLEpg2ehLK143v2kk81cH252D3I9wnFycLISYq1ex EYY_IrdNANGc1DEIBBNJYTZ2wpOFZ_VpfLrumrvI_yIXww89xzE_8jLNHV3mYCvtOgfzV8fpRiyG w4E7OI31teTHwMzOlenXlwjXAlQflLEXF7s1zO2SIQTFDQp9kISzeSnxsnf1b.onjiUzpDo_4WFu oFNRY0EBCnvDzgviYjQUY4dUG0MuuzR6aXbp6V50zvPWghEMWGUdD8hFp2meSMafQ39w.1QzQx7D 0lVspWNzYQL9t9AEgTOj7Y2xQmGPWQ1ehWB6Dz4g_fNU8lOPxcy2khU0CpDCuUd_I6G3QyF4atkC 5FyPBFccmEH_wd4pIoyBeA0TWk_b5sHWquPa_zvpCww0b0GoTAat99yo3AinvEtOhEZr0_0zhaY2 OUvdUpfmwWKBEi4QTafFfWO7OSdgWNhy6i9hI2sPG0q8gu05i.Bue071t17JUzcbmcIIH3rbLKGN muQl71DX7bRX5caKnWt_K5DhCHFedVzPz0HyCaycGCwhs5.09txcD5kkNEztJ_B5HtDo.NLRjAgV gDBmKR9bXZrX6nR6kUuyPT.RJKXqMRIQNIVce.EARIC1q6vtt20Qnw42OtsQQnaM4uaxwp2Add2K _2mBYf0zZoYagJozJ4TzCrD.9JtpMksWkUkI7C7OyaQGxjyDcDKII05lh91kJjQvMUplDphhWkKG Q8WxndXj7f_0YwUwHMDRO4JbL0jkfZPnwfouSKAc.0a0i6PJD.HOx.B9RaJGS9pp2bhXyMVVz.pk SZkObI5XpNJuwFXWNwZrFyJoHzw4It_SUG5xqYpWpEQVi3ubUe1QLFxLCCJtjsDJOIeIfRXokF_l l38rUM.AU5rLU27NPholTVEt.JHuD9vUA41WwI.OqUnOdfmqsGnk4eTwPDiVXR8xcsAFXTT86fUt 3u0T2hsaxQ3H_f13rR5DzKqqT4Cs26gaEIpQXSJCkdWkUIL9dIbFqx1DldcwNN2oVX6tArTWIpQH tqW3OFRyE30JGrzLPlF_5Y13bhijuFo18HpZl0y6Wcr7f1kRGlKcBBq2AHB_nK3N9UXry1LRhTsH s4ZNq2THywgyGB.5yBXYZVcr5PW.dDAA_b.RN80Dzm.N9wm8JkTH62hTqZH.I3OoPZ5JEPWgG.qH W9hYQwg7AD_Mah8eZWrq9svT8Zhv5kcBSAqgmlN_BC8PuqMfhsZ4pw_dVMKGLAwpF8XpW.GmAKMJ zeyaAeh1sQse7EYPuyhzLhcRWq.lMvLLqshohsJGbjJG0EgARBzQfY59tB8S_3DFHZ1krWq9VquR oVpUukKIWtg5sKbiF5pl4mWTuud9SMNmKD7HA60FXe_5nPOvumHp2xaDut6eVTXB_WlAweDvgYhV .VNQkwjUDkvKVEB._S9BWOd5Et9Xk8Two8iHeN6RoV2jyL83rHQx75SAV9.jEv_OmyqACdQpe_Hb ck3pyhBNhUPHRjmlkeBD5Ty3frnQfg9IZA9kZHOVQaLO9wab.NmaxSB1ELEmkePr9xZghwWQi6vZ uuqxkj4Bh9rqHycpgKjRqxLEL4fxq5WxCQQ6moNuE2XTUb1yw69rp5jv0t.I9Z3zyYKm.4YLi6zh m56WgkJlLdp2C_VSwObmrtC7e_nqHiWpvJ6RW3cr0xWy9NRaVj8P5jm2fWMm.axWfarvyVbsKDzF HBi8SunkwO4B_ky1YCJA72.fRvHJQh2S8HtuRhtdUPdnmgB6O.sM_MXFs6Y3.nTJhZOpb7OsPgHZ RznNacQ-- X-Sonic-MF: X-Sonic-ID: c202ffa7-72a6-4de5-9570-7c52b0a71fc9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Nov 2025 05:08:43 +0000 Received: by hermes--production-gq1-76c986f798-pz4gc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2740b6c5e94742b346186fe44d55d7c4; Tue, 18 Nov 2025 05:08:40 +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: Mon, 17 Nov 2025 21:08:29 -0800 Cc: bob prohaska , Carl Shapiro , Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> To: Adrian Chadd 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: 4d9XhM124qz3mRX On Nov 17, 2025, at 19:53, Adrian Chadd wrote: > (random reply, sorry bob) >=20 > i think i saw someone say they can trigger it with a single super = large source file, is that right? No need for parallelism, just build = that one file? I do not remember seeing such a claim about "p[i] =3D=3D 0" failures. All examples that I'm aware of involve both parallelism and memory pressure. Parallelism without memory pressure did not get have the issue happen in my armv7 testing on the Windows Dev Kit 2023. (Trying to test such on a RPi2B v1.1 would be problematical.) Parallelism with memory pressure has not shown the problem so far for aarch64 testing. > If so please pipe up, i'd like to see if you can get that over to mark = on his armv8 box and then we can try some stuff (like using cpuset to = pin the compilation to a single core so it doesn't migrate) >=20 >=20 > -adrian >=20 >=20 > On Mon, 17 Nov 2025 at 07:37, bob prohaska wrote: > On Fri, Nov 14, 2025 at 05:04:10PM -0500, Carl Shapiro wrote: > > bob prohaska writes: > >=20 > > > Those files have been overwritten by restarting the buildworld = sessions. > > > They tend to be large and diffcult to synchronize with the .cpp = and .sh > > > files generated by the crash. It could be done if it's useful. > >=20 > > At least from the perspective of debugging malloc(3), they'd be = useful, > > even if the files for reproducing the crash are not synchronized = with > > the std{err,out} output. For example, there might be other log = messages > > generated by jemalloc. > >=20 > > I need a moment to look at the code and step through what it is = doing on > > FreeBSD but my first guess is that there might just be an incorrect > > assumption about committed memory always coming back zeroed. That > > should be true on 64-bit Linux when MADV_DONTNEED is used but not = true > > if another advice is used like MADV_FREE on either FreeBSD or Linux. = It > > is always possible that the kernel is mishanding some memory but I = would > > like to rule out jemalloc itself before pointing a finger there. >=20 > Here is an example of both the buildworld.log file and the generated > diagnostic files, which for some reason didn't include .sh and .cpp = files. >=20 > = http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/buildw= orld.log > = http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbol= izer-input-bcaebf > = http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbol= izer-output-1aa401 >=20 > This host's particular buildworld attempt has been going on for a long = time, to the extent that > world and kernel are mismatched: > root@www:/usr/src # uname -KU > 1600000 1500063 > The immediate goal is to get them back in sync. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 18 13:27:21 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 4d9llq3r5hz6H7kx for ; Tue, 18 Nov 2025 13:27:35 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9llp5w5Dz3kJv for ; Tue, 18 Nov 2025 13:27:34 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-io1-f45.google.com with SMTP id ca18e2360f4ac-94900d3ef9bso113489939f.1 for ; Tue, 18 Nov 2025 05:27:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763472454; x=1764077254; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6+2P/mGKsi/SNoqeMVQ2Eub+neimLIFAfFG1GnbJ/iQ=; b=fGrkfizv4RCPpaQUM3nqMGNcUpUZ7PJubKKBe2T4JdhlZEOJKPmCWGvyYJ9IpjXP6q TK3zoKHFFSPU/6vo6zAN0R+TU9bNz58nfnHYqGD6MRzn3VW3cnLgBbu7F2aRAak6FMV1 5gX8c4ZZq1at+t/+FL4QlwBftwC1fxbjf03bzXk2OekByBk+hNNgkt1X3aivh+aMkV3M +lplWm4WmiGYo8RzMPf+Kq1mg1GlxJHFN0RlI3cvabbzK75eYIhHQSjzXklYVfFvkjFO YzpmFkvGaFrjOqGvE3/EZq1OzPE+NMbHp2vfkeMcf7LIvW9m7jb6xMZZ9dJgFT/8nwHt c5aA== X-Gm-Message-State: AOJu0YwoXGIthlRW+on30GRPSpxwIpxohLcIeYu4UOVRE4HeEMftMGtn TWBB3bEYGH14uAv7UD6AuWO5dXw2AcIbh2Gl1AuhEapAuc+1c8lTy3PxgESgEcImms071R0j5v+ gHL24F2rJq0w8CRDEH6UR+KrEvhB+3Mg= X-Gm-Gg: ASbGncvis2JYs/CXdKnjdfwUE8HNRUTUjxAnlpplYyci7/JuhdHo33gccRAW5l8FkBR F//xyYccF2MfySdM2cabkswcRo7GU+s7c+jY926+HVpzbI3mUlGSVnV1LJrXGy8eaYQPByhlygt uOFW0eIGRn8dEJ25HHl0CW4jwQOpW/IE7CPMap31KIpyeJl7CeZkT94K2SRG7S2No9E9QGc1tHr vfZFDKkjvBftkdQBByFjhWf3gc2tAnvTymNfzF9W+nyTPYm3hBNwob1a/jdHlJDJYYNDRSiCM+U 3+9OhQ5Biz5s/jfodvlbT9GQENnbR3cCfDhYe1FnqT601+4ZwjdF+Uqz4S6f/95/PZC1z1nEtdJ oT59khNo= X-Google-Smtp-Source: AGHT+IHBCQLfWyaLd4JwaFLUmQPbinI3U0psetXov+ST4DFH6nlsSfGFKh6EiYlGFh9noPHXDpuVoZCNRAuo3N/9MtY= X-Received: by 2002:a05:6638:304d:b0:5b7:d710:660b with SMTP id 8926c6da1cb9f-5b7d71066bdmr14488075173.20.1763472453647; Tue, 18 Nov 2025 05:27:33 -0800 (PST) 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 References: In-Reply-To: From: Ed Maste Date: Tue, 18 Nov 2025 08:27:21 -0500 X-Gm-Features: AWmQ_bnPtJicsU_onL8d5hWle7so4PGVD79U0FRFhwYSJyRhL7r5f2Vq_Wk-hQ8 Message-ID: Subject: Re: FYI: getopt in /usr/src/contrib/diff/lib/getopt.h vs. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/unistd.h : reported as incompatible with future C23 use To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.81 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.914]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.45:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.45:from] X-Rspamd-Queue-Id: 4d9llp5w5Dz3kJv On Sat, 8 Nov 2025 at 11:10, Mark Millard wrote: > > In file included from /usr/src/contrib/diff/src/diff3.c:32: > /usr/src/contrib/diff/lib/getopt.h:154:12: warning: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C23, conflicting with a previous declaration [-Wdeprecated-non-prototype] > 154 | extern int getopt (); > | ^ > /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/unistd.h:384:6: note: conflicting prototype is here > 384 | int getopt(int, char * const [], const char *); > | ^ I think we can just remove contrib/diff/lib/getopt.h and use the system header. I've opened a review to do that in https://reviews.freebsd.org/D53802 From nobody Tue Nov 18 13:44:55 2025 X-Original-To: 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 4d9m7t4Mrpz6H9Ss for ; Tue, 18 Nov 2025 13:44:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9m7s3SL1z3r83 for ; Tue, 18 Nov 2025 13:44:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 254DFD7891 for ; Tue, 18 Nov 2025 13:44:56 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 5AIDiu73006266; Tue, 18 Nov 2025 13:44:56 GMT (envelope-from phk) Message-Id: <202511181344.5AIDiu73006266@critter.freebsd.dk> To: current@freebsd.org Subject: 15.0-ish urgent: Please test iichid/keyboard patch on laptops From: Poul-Henning Kamp 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-ID: <6264.1763473495.1@critter.freebsd.dk> Date: Tue, 18 Nov 2025 13:44:55 +0000 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[phk]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4d9m7s3SL1z3r83 If people running 15.0-X (or -current) on laptops can please test: https://reviews.freebsd.org/D53803 I would really appreciate it. I have seen two mentions of keyboard related bogosity on FrameWork laptops, testing on those is particularly urgent. Absent adverse reports, I think this patch should go into 15.0. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue Nov 18 14:04:09 2025 X-Original-To: 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 4d9mZJ2DXmz6HBlH for ; Tue, 18 Nov 2025 14:04:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9mZJ0GpKz3v94 for ; Tue, 18 Nov 2025 14:04:24 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-63c489f1e6cso4527410a12.1 for ; Tue, 18 Nov 2025 06:04:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763474662; x=1764079462; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8cZoEd10pG85QI+P/KmvH8dCvgFM92Zgs3AkpY724PI=; b=rXBgYUlCjpZKxKBZSuVt/oNdNY6Jrl3c+oNI/VB3/lEb6Ku59GZkSDCwjgJcu3jZ+x 8JDl8vQDEbDvS2h9STXm17bf/pkTG56B+PC3qGmJx3mQdnPdN7JrIAyrjFKoRP21FPgb J3AZ2VPMTh3IVDKkDkCZLz6vHU0+eJIQ6Fx12NsrgJIl6eIGhie3+E4BPFm5eKQJVfQU URfnD4EmSxL/wwPlhBof9MrlLWMnuQpOimYhqN8pqKiq0+4W2zQTCeiwSNNaKdTwxAiI BnqIQ1Fx0AksZhJxj7snqkcOTRdFTntQnWFAhukvLRIT1e1aTvKZx1A5Hem0cMxLK3v7 TKmg== X-Gm-Message-State: AOJu0Yzu6yflUHLlCHj3Ppv0Ddh4BgmrhaCLU+Sa0NXIFIEe52fnIVNk QXT+G6NvssXCsmdU9qEcruVnjnC2RFX4SGxV4K1NxBVYX9oKQNrdVctAjshem+V4/SEhRC2RFUJ x0er3hzB0H8BWny+mnnxqeL5TNvilhVhFaQ== X-Gm-Gg: ASbGncuFrUsZ9wP4ZuJc6HK2Zkg+rdxSN8eTchK6APELyhOKHvqXjJKjNISD2gmWhno VFbTV30rGD7Hv/bHrfm558D9cbG5xtAvSB0RhYUURDr5Yh27Ju2lqfUeHaoJ0r4unhPocZkuAfJ NbvYEC4wVQ1xjzWfFd8FRB0uCN2QohkrPyXu775qEB/8qkTbXiC3Hhx2/Sr7jtcy0tWt2IkuAbk 883lJnP454XCHLqOZhHYBaTq5phLB5qop+EZwP+rFc6novryVmTWO3UsNvZx1WFRYKMH+Y= X-Google-Smtp-Source: AGHT+IENxoVz8k7CG24Vd4w/KyAFYqiZdakxCqX6jnJHH1cqhyryfQ9NYG5emxiVJUEvosQtEVeaz8m77ddW/sAR/NA= X-Received: by 2002:a05:6402:c8c:b0:641:6582:6c1e with SMTP id 4fb4d7f45d1cf-644fe9b1111mr2353458a12.10.1763474661883; Tue, 18 Nov 2025 06:04:21 -0800 (PST) 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 References: <202511181344.5AIDiu73006266@critter.freebsd.dk> In-Reply-To: <202511181344.5AIDiu73006266@critter.freebsd.dk> From: Alan Somers Date: Tue, 18 Nov 2025 07:04:09 -0700 X-Gm-Features: AWmQ_bnyVniQTZ84hrfGNYza1csZB4gT8k4Ryta3Z3N3Oiul_q6VOLFoBx69xbg Message-ID: Subject: Re: 15.0-ish urgent: Please test iichid/keyboard patch on laptops To: Poul-Henning Kamp Cc: current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cac2bd0643def027" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d9mZJ0GpKz3v94 --000000000000cac2bd0643def027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What kind of "Bogosity" should we look for? On Tue, Nov 18, 2025 at 6:45=E2=80=AFAM Poul-Henning Kamp wrote: > If people running 15.0-X (or -current) on laptops can please test: > > https://reviews.freebsd.org/D53803 > > I would really appreciate it. > > I have seen two mentions of keyboard related bogosity on FrameWork > laptops, testing on those is particularly urgent. > > Absent adverse reports, I think this patch should go into 15.0. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. > > --000000000000cac2bd0643def027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What kind of "Bogosity" should we look for?=

On Tue, Nov 18, 2025 at 6:45=E2=80=AFAM Poul-Henning = Kamp <phk@phk.freebsd.dk> w= rote:
If people = running 15.0-X (or -current) on laptops can please test:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://reviews.freebsd.org/D53803=

I would really appreciate it.

I have seen two mentions of keyboard related bogosity on FrameWork
laptops, testing on those is particularly urgent.

Absent adverse reports, I think this patch should go into 15.0.

--
Poul-Henning Kamp=C2=A0 =C2=A0 =C2=A0 =C2=A0| UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TCP/IP since RFC 956
FreeBSD committer=C2=A0 =C2=A0 =C2=A0 =C2=A0| BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.=

--000000000000cac2bd0643def027-- From nobody Tue Nov 18 14:26:08 2025 X-Original-To: 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 4d9n3Q4rxBz6HCx1 for ; Tue, 18 Nov 2025 14:26:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9n3Q2RsMz3xcW; Tue, 18 Nov 2025 14:26:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 9B63BD7891; Tue, 18 Nov 2025 14:26:08 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 5AIEQ8hN006432; Tue, 18 Nov 2025 14:26:08 GMT (envelope-from phk) Message-Id: <202511181426.5AIEQ8hN006432@critter.freebsd.dk> To: Alan Somers cc: current@freebsd.org Subject: Re: 15.0-ish urgent: Please test iichid/keyboard patch on laptops In-reply-to: From: "Poul-Henning Kamp" References: <202511181344.5AIDiu73006266@critter.freebsd.dk> 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-ID: <6430.1763475968.1@critter.freebsd.dk> Date: Tue, 18 Nov 2025 14:26:08 +0000 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d9n3Q2RsMz3xcW -------- Alan Somers writes: > What kind of "Bogosity" should we look for? Probably "Keyboard not working at all" since this is something that happens only during startup (and possibly resume ?) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue Nov 18 17:45: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 4d9sTs15SXz6HVXF for ; Tue, 18 Nov 2025 17:45:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9sTr31ZBz3G1v for ; Tue, 18 Nov 2025 17:45:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-io1-f43.google.com with SMTP id ca18e2360f4ac-9486354dcb2so250956339f.3 for ; Tue, 18 Nov 2025 09:45:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763487951; x=1764092751; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WwY137BZUqKO6KJacLN3qaHytynbCfTSA/hAN5VL1Dw=; b=SQO9Or26xaWKmFXXAT5WB7l74f+iUaENsc16Duuukd3z7H5uKQR1klI07la8gtG1hm eOwIIaRT4ZE+dJPWb2CpHW+jmuoNhaGMApu+bSK/4BaL0j584k+ZJD4tuM8igcnfGT2S Sb+rg+l0AKcED8vZxHwjiXDe6dgEh+Nj039Xxf1TAwxIQz2+c0qA4ZWTUj7SBa0zZL2r XBIPWiuMAZAyuNcbW9yKvzAmYS6VcMgEMg/ks2yDagL8CneMI+LEsAkEqXRIoYGURFPt i53OEbRiGqYlUflrL45l2RMlzum3B0VFddnen8w4AYAMHkPleEhFbgB3v2F9G5llZcxu piBQ== X-Gm-Message-State: AOJu0YzOEf7ri5kksPyPy+uVhBp70OihCxenZKb/573/mzf1TShdZTAg nd+JTbrd9R9P/X6wqDEaCQ/DqcZwDX4jpdvpEbfsqjK9VePG+ispuQ4NqCTbZ8m5IYzIZ9OvrKS tJZ15uEmBYd8EXSn4xvN9xW6LCfXNBwf0cwjR X-Gm-Gg: ASbGnctgYwdANbqPRTz+y0UbcujGF8c8KIU4QJlu8//lSCyquLZAQ1qZTrgBKzIYof0 xc0nbSyuN3GIH6smy1iRZwEyiTRMR+4HF4/a2oj9KZhLHl958bL1h/uVs9euh8JmYRjHcjj0sFb wiWG7Iy7hUhSlr0gWT08AyVetniH+0Gu0mfcXpPQDjMU/5+XWTp78HvPrvJoAnUl0cHhAPBB33Q fUsF784fs9WZYa71WE3eof0tJVA5IZssBudKzOlBKfVEfZ3Y0eK+kstN4f6E4/SeEtw3pQTcWhq 4Rd0TIewR9Jg4ya3+k+yEHz1L9U= X-Google-Smtp-Source: AGHT+IGm2S+69RrnkdKLUJpFnx6aEX/d2y8owBOcqbIJhf2HacnDSmAFbeM/LZitJ9d6Kg2XtbugimAaUkStnzpY2uk= X-Received: by 2002:a05:6638:830d:b0:5b7:d710:662c with SMTP id 8926c6da1cb9f-5b7d71067d2mr13894378173.23.1763487951200; Tue, 18 Nov 2025 09:45:51 -0800 (PST) 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 References: In-Reply-To: From: Ed Maste Date: Tue, 18 Nov 2025 12:45:40 -0500 X-Gm-Features: AWmQ_blb0Drgtl1Z--Lj9N0XH6XaDHGefeqB_gJH8gBFOLeQZMohdDWhYSuBFV4 Message-ID: Subject: Re: FYI: getopt in /usr/src/contrib/diff/lib/getopt.h vs. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/unistd.h : reported as incompatible with future C23 use To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.43:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.43:from] X-Rspamd-Queue-Id: 4d9sTr31ZBz3G1v On Tue, 18 Nov 2025 at 08:27, Ed Maste wrote: > > I think we can just remove contrib/diff/lib/getopt.h and use the > system header. I've opened a review to do that in > https://reviews.freebsd.org/D53802 This change is now committed, and I have https://reviews.freebsd.org/D53808 open to address another warning in diff3. From nobody Tue Nov 18 18:18:04 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 4d9tCP1XZPz6HY7T for ; Tue, 18 Nov 2025 18:18:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4d9tCN4jz7z3MqN for ; Tue, 18 Nov 2025 18:18:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=g2Qqgeq8; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763489897; bh=w3dK32I64g1mxYR2cyml/RanKa97whcW/w5zMbFtXHo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=g2Qqgeq80gUVQoRInqPr3dTNTIG/GlzZfK6pQy0WbyUMXf11XQkLrA29yJZVxA+v1mKv7HKgYNnJWyOHFGbtxblSabNog/1oMLAaDXrjLK61nCrU460Dw6VhjyoF33i5F7KMl5s1qmaBwS11RPnGFJPsTwj+vTNRUqVXwpsJeV8+p4rL3ua6J9Z7mfmviQO8iWafsVYkBf+rFHMFVruftOFELLp3CLn2JlT4YllfR3Z5mLSqI7g8QnOV7Njouqt9pnvYByCrmuTvWAsqAxOcY31GrcCo2CPiuDk05BIwlJkTk4aSc1KcJmHyARL1TTq4iV/q9e6P3vwZWu8nQ0GVBg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763489897; bh=gzDKpg66bv0rYhIKWztYz0EoVqvBk1fccK8fBOjv2v4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AkvpydMxe2ASmzO/nIEVpVzP/hEuc3UXicO1uftz1N8cjFKZc75Y9VoD1FEZLsi9tZK+Vh2YZaX7Fx4VR+U4GeKJXeTTRZYLqTfKkOtqh+z0Z++J1CCf2wCCqn8uQQvzfMzAxZ5xduSP4RulFQfRw/1++3lHSFklHyMCUPA991H2Zha94ZENqfZLIrMHmG5Xysc5nAub7qr+Ueo+76fD8JZQ+veT7ppqEsahmdcRrWd4dMsr7DElmqZv8J0R8WTG9qZ2D/M9g6ZuvCiGruVcJ31LEHw7YNBJCU5ShWqOT4tnxF1ITgbAO2W0V0X/toMNS4krj+0CC/Nygi8LQOMmCg== X-YMail-OSG: hS6sNicVM1krWQTe0BVk711PyFmmZkxDkFF76EIL7JWiZudU9QRg60LGUx7wV.d TURCZriNuYgKXA3WeiYDstHKKul4kEYExwOB.roI3iS.LLejngPshXEfjVCyxmPoNCXVUwv2MPQX _B00fKILSWDBVJ1KJuV7RFj3FP38SppBn9wFSfLz5XfRR.vs6xzujn0PRroKS0UHklfWX02C2d90 qj0UZIFFhKVrg0MHCA3OgzHRJtMqebuqoRoq_6IKItd77gL_ZniVsgPX7S_1BcHqIuMhqwx3fk6s 3Vy2q32H645ZMai1vstlSIsYx2T664jcL6c9DQaBYH1vdtvcMqy_dzECoggpLCaMhg6oSxSOnp_x Hd5qwc2f2o6YiYPA37ShsFGaNa8AqssZHM8kMJRZwFc3Dg_5LCGGUafHGySfPz8w1I_zUhkcSSu6 9RmCgmEnsn_SVgTSwCvY1FZVCEFbNUBGCbzm1.EizzVvlVGB672iYw7IgTyCKzElv7Yy.c202hOQ TqgcVyNdcKNpJHsm2a.gJ2XELeEI2TXadN73UcNzLBfkdlmpV4YEgChhFo8V8e4KgN8xzC8ok4xE 0GS71Q8SlDqqzK3DVZ0FxqsDQLj_VP.IHJ_N5kTKYDTWm9Zq.SUJNPQEELpLdgd4ZZB2vEOy_6Ka OcgO91TvirRZp7SsRgMjz3ZitDqHXreaADr2LijzZgdL24FBE_slYm8e8YSbSYycQ8tOxBsvyrzs hNUKcXlS6ym9DZ8YZJEqXvZ1ztYEWMAJ_Ox5nS6j8wnQ.HRBGJ19n3F6jS7VrKqWyrCfKB3.0wQk 1wC8cE3tZW.g7DAs9vGSxDwmxh2N3qtieEnZjcMDF3l2LIjkIvQDC8NVAR8os1QMUQm6gpncAT3Q VzYW.fchfNKxTEDPuaXY.cGbPtGqZ6B2HnTtFVYSF2E0KLO5eOhyMD6mjNUCrjO81oo9FLqgD6mS 7woJBXNaMVYral5fy5c1jUTAxwBAVCuLOGp02H9owo2T3p7qeZAMq7MsHG9U3RX8gUtRxXrmsgPu stapyZ4IhzOZNnjxePieNG8Pn6Fb2bWxD4CyEZESt0vdfQZV4yFTGz4WzrAbncFvFh8WWtVNbE2d KRswYNeyTmnRI4wDpQ468oSISmUlICI6C8WRdRw4Y1tuq.eI_HU7P5Cfd8ql6TG3._YR5CD_MDcT 2OgF4faqbZc6hDwbCx1tSLq_s2pMW2v1ewNsYH24GEcug3KBWkO2es30ykbw7oxkXHM3HSKmyFDB 3C1lkkYs14Rzzrxn432rrMoAY8s6gDRV7mkJWAbhsWcG2Nq49t4wn3oxw_EZ7FL_y2GtK2vJ8rSB kroXAo9jbkY4IVEbZHSK.aM3TMRgpjBcxPuLZSq_okrHBtS_n0i0ObYBJ0UpFAU9.T_D0Cz12AlD WbWCg4Z.JhFTn.IuGSvaaa_jw64YwvrULJWTncLHfYKqb7oBqZyrEt7pPCOROrhDsSjO5tlGo9I5 YdJ3UdhwXaDovDTQF5CR0yfud9hpHHxueb.UA5cOtNpY1Vkmo6XCDaETkuPK8wvDLuskdet4Ox2M BvQFCh2Dp_B5FFHjIZZ1oBkT6TWer93I_2h6L_XQIoX9Ee0ydOGgK.Sb2TbP72TzpRf4WuVFrXjB AZFp8R9RR_5li9lREOetVHwVjeJy56KdYzFj1FlRRiIcVsbAUfy3u0QHuL2QwFGNuUV28vEDRhB3 xvAFKUYrQVyYZJLK4ons5q_U1p_d_YLHpj_NHp16JVZik9jm5rStciefynSi109ZXKx31DnC84bU w3MntnSdT.DWeF0dJflxGhmHhD..LNyAFgFk4JQjjRBjDTOc.6Dp__f1Q2JUAhwfcW1KcuPqzqJA ypEBOIm.BrZPMVrUFn9REqIA7gBirj_QqzH7ScfxGczD8MAtAuHkqotDEFaqVA0LUzmtYOTAip4n BJYyw27anr2JiJCAwwcRBFqW8ldcW5VuWmH5h_Ele.6k3KWvafsNADzEepiJicHLDZG9.JsfwUD4 RdfyG_QoiE_laCeyvhOZALWWu85eBNcDQjBdGHpeQhfJZ_iM5VxqtlSyTX_15LGQTbyGk.g5en8c BMPG31kBEto_qN.nrdu37oVA5e8rEihTbmcJtpTLfMliLSp_xUeJWM_JvEC8taFvoY6HAvzAvZ1B r7Ii0LadCnwpb2nL4ekFVbkdkNAEUn0d3Sov2KyA4Wi0i9k4.CGkiUqVpf9PjH8C5ONn4BaYUzJQ Nns5a5qyiz8Q37KLWfF54JyXdcIZjTEMNhYFquZtcPQSpdZ.d1mub8VhskbyHqt.S0RODZDRCa8H amlXLmLez9lHILeM- X-Sonic-MF: X-Sonic-ID: da9746ad-5fcd-4c4c-b684-ed3226f066a3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Nov 2025 18:18:17 +0000 Received: by hermes--production-gq1-67d9c848cc-7l45w (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1dab1d970715f278b8c8dc0d9360d674; Tue, 18 Nov 2025 18:18:15 +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 [gdb backtrace!] From: Mark Millard In-Reply-To: <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> Date: Tue, 18 Nov 2025 10:18:04 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.937]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from] X-Rspamd-Queue-Id: 4d9tCN4jz7z3MqN I modified system clang to not register its 2 SIGABRT handlers. The backtrace has the jemalloc call stack activity as well. (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2b629000,= size=3Dsize@entry=3D12288) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff6f17, commit=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D12288, alignment=3D4096, zero=3Dtrue, commit=3D0xffff6f77,=20 growing_retained=3D) at jemalloc_extent.c:1003 #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 expand_edata=3D0x0, size=3D12288, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D12288, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D12288, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 deferred_work_generated=3D) at jemalloc_pac.c:178 #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D12288, = alignment=3D2147483615, zero=3D, guarded=3Dfalse, = frequent_reuse=3Dtrue, deferred_work_generated=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D12288, alignment=3D, slab=3Dtrue, szind=3D25, zero=3D, guarded=3Dfalse,=20= deferred_work_generated=3D0xffff703f) at jemalloc_pa.c:139 #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D25, binshard=3D0, bin_info=3D0x2a21ff0c = <__je_bin_infos+1200>) at jemalloc_arena.c:839 #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4528, = cache_bin_info=3D0x2a6004f2, binind=3D25, nfill=3D5) at = jemalloc_arena.c:1034 #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4528, binind=3D25,=20 tcache_success=3D0xffff70ef) at jemalloc_tcache.c:238 #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D25, zero=3Dfalse, slow_path=3Dtrue) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 #15 arena_malloc (tsdn=3D, arena=3D, = size=3D1536, ind=3D25, zero=3Dfalse, tcache=3D0x2a2e42c8, = slow_path=3Dtrue) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, = arena=3D, usize=3D, usize@entry=3D1536, = alignment=3Dalignment@entry=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8) at jemalloc_arena.c:1224 #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, tsdn@entry=3D0x2a2e42c8, = usize=3D1536, alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, = is_internal=3Dfalse, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D1536, = alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff71e4, = dopts=3D0xffff71c4, tsd=3D0x2a2e4060, size=3D1536, usize=3D1536, = ind=3D) at jemalloc_jemalloc.c:2398 #20 imalloc_body (sopts=3D0xffff71e4, dopts=3D0xffff71c4, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff71e4, = dopts=3D, dopts@entry=3D0xffff71c4) at = jemalloc_jemalloc.c:2693 #22 0x2a15677c in __aligned_alloc (alignment=3D8, size=3D1536) at = jemalloc_jemalloc.c:2821 #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D8, __size=3D) at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 #24 operator_new_aligned_impl (size=3D, alignment=3D8) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 #25 operator new (size=3D, alignment=3D) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 #26 0x2631dde0 in allocateBuckets () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:915 #27 grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:849 #28 0x2631dd0c in grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:580 #29 0x2631dd0c in InsertIntoBucketImpl () from = /usr/lib/libprivatellvm.so.19 #30 0x2631daa4 in InsertIntoBucket () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:590 #31 FindAndConstruct () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:369 #32 0x2631d49c in operator[] () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:373 #33 analyzeBasicBlock () at = /usr/src/contrib/llvm-project/llvm/lib/Analysis/CodeMetrics.cpp:234 #34 0x28e2c3ec in run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/FunctionSpecializati= on.cpp:643 #35 0x28f4fd70 in runIPSCCP () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:165 #36 run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:403 #37 0x27b85d14 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 #38 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 #39 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 #40 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 #41 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 #42 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 #43 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 #44 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 --Type for more, q to quit, c to continue without paging-- #45 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= #46 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 #47 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 #48 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 #49 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #50 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #51 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 #52 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #53 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 #54 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #55 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 #56 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 #57 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 #58 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 #59 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 For reference: . . . Building = /usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang/CodeGen/Backen= dUtil.pico . . . Building = /usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang/CodeGen/CGDecl= .pico : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" . . . _ERROR_CMD=3D'c++ -target armv7-gnueabihf-freebsd16.0 = --sysroot=3D/usr/obj/usr/src-investigation/arm.armv7/tmp = -B/usr/obj/usr/src-investigation/arm.armv7/tmp/usr/bin -fpic -DPIC = -UPIC -O2 -pipe -fno-common = -I/usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang = -I/usr/obj/usr/src-investigation/arm.armv7/lib/clang/libllvm = -I/usr/src-investigation/contrib/llvm-project/clang/lib/Basic = -I/usr/src-investigation/contrib/llvm-project/clang/lib/Driver = -I/usr/src-investigation/contrib/llvm-project/clang/lib/CodeGen = -I/usr/src-investigation/contrib/llvm-project/clang/include = -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER = -I/usr/src-investigation/lib/clang/include = -I/usr/src-investigation/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd16.0-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd16.0\" = -DDEFAULT_SYSROOT=3D\"\" -DLLVM_TARGET_ENABLE_AARCH64 = -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_POWERPC = -DLLVM_TARGET_ENABLE_RISCV -DLLVM_TARGET_ENABLE_X86 = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-format-zero-length = -fstack-protector-strong -Wdate-time -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-parameter = -Wno-error=3Dcast-function-type-mismatch -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments = -fno-exceptions -fno-rtti -gline-tables-only -std=3Dc++17 = -stdlib=3Dlibc++ -c = /usr/src-investigation/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.= cpp -o CodeGen/BackendUtil.pico;' =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 18 18:39:06 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 4d9tgf5zttz6HZ1L for ; Tue, 18 Nov 2025 18:39:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4d9tgf23NRz3R6P for ; Tue, 18 Nov 2025 18:39:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sEf3rVzT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763491159; bh=CzqY5yBjkEP4w02i8BdarizIPAYKGlIeeUZuvxX6SCE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sEf3rVzTkCaInwUR377CYUt8PF8JV6qKVa5RMIeMQN2M8heOksNJgBDqRFNjcLqskijHt+kqJhrnJL7Gr3CfcZ+wMEv3MkkWHIUZrbYHCBdqTmIpO0mB5+C7yN8nCL8He8hDoPUCGrsSnrhdq6WaAJTHq3sjkCdkhCAenSkuNsQ7ulNoP8JqFpBGqxddJIKM00AUGt5T3UhYm7ZJw4udDsjoBpqRzMkdPWuZSSufH/HCgLvu62/720lhixXbDfsDbyelzuia4tWHITFW52TqN1tSyNy3foJfyWviJPzgN6BhtmLW5Y8zZ9prX5qGz1C4Iv5FCupgCFedY3WOAmQ5uA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763491159; bh=n21d2J7n4lyXUa/YQvu3XJkDW9SLpCaHISaNObYbDZB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Q2mdMzHJnB5l9xBh35aw2xu0APVS20wnhqWSG03yqJDB7Qf+tO0DTyzh2XdbxpX/DZeOl057GMKQJGawWhSTGOeDnmFp+ImFEgmKJaobuljfFhjzHtmo/WTq6DtzKi42ApQ2hzOfk8Mk80mIgWbl5183qib0yizlzT7s8YOvd2olUHVZN4oKhd6KeRA9ekqpt8p3v7LP06Ld5MO5BxJtPiN4xlr11qfq55Zb2+g2VV/+DJF76/uREXF78t4BIXbmG76l8LX/9R02EmyKOaR/yUlyfNt0YyI0sdhBCTh/PZfEjzz0l4FBsNKI4Q+wpGRy7AvfCWtIxz1+2cowIEoIjw== X-YMail-OSG: uLSpHjYVM1k35Lu3z7H5e0rd4CyfGWUFazpagZGxgVKhlse7a3YIGV4gWr75VLM Ua8wFosMrv8WtFJBn0Uwj3gZxRBn974rnt8w8UvfYiZKDfScBshVV271qv_aGcHF_2DekfwPEOKk HDx35qpiRdNYzg4Mw5Bg7lHV0y.sVvkSUMkLtlD7z.uSnk2Db31pgf3LKIQzuGx3G0EV7ID1BNkr xM4hsxea4QekDJp1PgZvxUS1RWg9CJourHhWwoP3Q0IDzuNjaRvi4cBkT9jZ60FZ1QJP87.4asyb qHJZ.acsvkbZoXkG9j7odoT6ZZ8YH23s0aPtvlDAb4yXfUNwwHHHAWL4wPrNNYpwVfZZqCIg2WMH fjW3yR.XKIdrUDloKvGPDSOQN8MG_f4AWkmascgONjigg5o1NP0mGu0IB_ntdgAXw3JFuQnsojal bdzZb4HCzwtnd3tqH9.ibKsvlMJzGYvYrNTW70manAFzfCQ49uKTrhn05PNC0sMv9YiFlL.XmIf0 GVxG8JpYim_3bzQe.gIGQjbxdkei1EvXCB9GofRM6yYiqiCRjMfhjnhAxsTe_7w35KtoiFdSEMZE 5kIjtQd06RZPjRXoPppq2HP8dRpvHEovY9FMlVS.AYqr4kNAm_ZTejTOoWgjwFV9ufHDvC7allnL .CPR2s94J6yQqD8oRw8sYrSVA_GguLcIOzxmRJhHCuwwRy52a1rGGRsxzSmVzffD3UZDPKUuvqps JL5cZSiKop9qjxghjKJcVGjIrdZdA94DEv1yEpEinEMLm7WgmLDnHexJgJvp0wj_5Fwn2EZxQ6_h uNIE4t3QBMwu.ycJpl8uAayiQBo0yKSlwfu4PYc4UFgknLxo.Zb6dwoPHzk2BhD9jD8I8aVd7VU0 e.i_IodNKAqnEK4pkdAZjTjrh7R_GiwpHgF4FooszUoplKaQOhqeBqB.lq2fkFe4_Y7_wiGJ2qYS zISldTgyjWqD7NIAoXYFWxQPlPr4R1HE3jLesBAa76iBGii8p7trjXAd79LOVVZCf4hjmE5r91bz WCWgS3MYKpFduSFVRCOZ6_j4m4YfWQXsJrAnloyXfB_aJmVjqwFpSOkZupfd4o4gUpdvcjhRnLq5 0iLjNg5f6TTuZTPwm0bblCMKGCP67UE9tzfeSsvjLsAdkjrusPK5Jk13flJ8QHkoiimEfVb5fko5 BQ6QNLNww4Sx790fbMGil02TODryP6GUdKGkRPjqIfpt6zR8zBcA1k784Mg.gfB0BGdrRe7pCCdJ NA90lIZMOEt6bnDiYuHtuxABL9QzclMHjN9AyYsjqvCitl.nRMbdaq28QtNdWcUnUf08o47Hsd71 sfAAI5Uev6I_wJiyt5yBCdWFrJv4EVy6DOPBho62j2u8i.Q.jigBAGpReXnoxagNZ2W_0fMNVgPM lsPsaCDxpjreairLHvCBL2qi5CdiIYO1jTohpYfmnQxwxNmcQ4olQolTWmoAHfH.S8jbyah_ByG2 zst12xzfEasANpEGwaPvpIsYP5CgBIaXG4T5K.Gfb4u8mggkn.nwM9ylENLsvnCF0KRAE2UuMQyc bQQbbceZJJPkH2.G9pYYc2OAj3b07sq2.4VAvG6iLrqGmEPgVIDeSGd2RN9CYDhC_KL7Hr.ghwqb 9v5m4pPeIj_6wkuZmPOdy3stikdgzOfFM6lxSkhFJkXiqiYsS7gX0Y_FYuPMbGxVXOkKoPILyAl9 yrlLxolYrhJyo_2_LkTvs.Yp_7xGQZOalTOLjGUgHMG9m._acVgYzAEwvmxRnIMQ1qLOZ9dXKw5b CVDyLWfQRCbWpndS3Vl7rlD3gmrz_.pSL4tXKF617ZoR_dS5_mRLxUiPwOrX_oYHTEvgDzlNiUJm wGFSGuE.iY3kNM1VKZh71e9G.9mJkxCwn5BGLhdTGgzke4TNBG2NuwtQbgfTAKyb0N7oYcxo7sis siVbybXkmw_20Lsu80ItQtJFGRsgVS6ph8Hw_4JnW9HlWPbwgdtpjD2UCA9AcODbUx5yMRO7xREt xXVZfhd2VkogiUKP3XsssKoyfVukrtLLiQn2EHQskT.9TlhrpCaJ3l.OegZ0_wViHJcC0OkOasMk T51wUhrKsvI_hqG2m7OPX.NRJVK5A_K6bNJoOp2F7a5qgFRVE6rvQLGMEoMwjVhZXLzs1zmvXRBQ jSIP3Zm7XGOnXG5uH6hEY3VB55lzVHtqXDeNfiquDdhMZdxlvJTwZUwhlUgLghAS6gG.kWK8rgfY MJSbM8kKw4lZi6OJvxAZe8WvfOoIZ_R41ezTfr2ijDw45xRMzqMTC2VDEOXFkXTsT7vy0VCLKnkX kK1WQdW0PLav.B7L4 X-Sonic-MF: X-Sonic-ID: 75c001c5-7679-4d7d-89dd-425ba945e89b Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Nov 2025 18:39:19 +0000 Received: by hermes--production-gq1-67d9c848cc-bkpb7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 42f50bc66de0801b657dc56b066914ab; Tue, 18 Nov 2025 18:39:17 +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 [gdb backtrace! End of area has 0x5a5a5a5a sequence] From: Mark Millard In-Reply-To: <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> Date: Tue, 18 Nov 2025 10:39:06 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.939]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_HAS_EXCLAIM(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4d9tgf23NRz3R6P On Nov 18, 2025, at 10:18, Mark Millard wrote: > I modified system clang to not register its 2 SIGABRT handlers. >=20 > The backtrace has the jemalloc call stack activity as well. >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 > #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 > #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2b62900= 0, size=3Dsize@entry=3D12288) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 > #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff6f17, commit=3D) > at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 > #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D12288, alignment=3D4096, zero=3Dtrue, commit=3D0xffff6f77,=20 > growing_retained=3D) at jemalloc_extent.c:1003 > #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 > expand_edata=3D0x0, size=3D12288, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 > #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D12288, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 > #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D12288, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 > deferred_work_generated=3D) at jemalloc_pac.c:178 > #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, = size=3D12288, alignment=3D2147483615, zero=3D, = guarded=3Dfalse, frequent_reuse=3Dtrue, = deferred_work_generated=3D) > at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 > #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D12288, alignment=3D, slab=3Dtrue, szind=3D25, zero=3D, guarded=3Dfalse,=20= > deferred_work_generated=3D0xffff703f) at jemalloc_pa.c:139 > #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D25, binshard=3D0, bin_info=3D0x2a21ff0c = <__je_bin_infos+1200>) at jemalloc_arena.c:839 > #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4528, = cache_bin_info=3D0x2a6004f2, binind=3D25, nfill=3D5) at = jemalloc_arena.c:1034 > #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4528, binind=3D25,=20 > tcache_success=3D0xffff70ef) at jemalloc_tcache.c:238 > #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D25, zero=3Dfalse, slow_path=3Dtrue) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 > #15 arena_malloc (tsdn=3D, arena=3D, = size=3D1536, ind=3D25, zero=3Dfalse, tcache=3D0x2a2e42c8, = slow_path=3Dtrue) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 > #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D, usize=3D, usize@entry=3D1536, alignment=3Dalignment@entry=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8) > at jemalloc_arena.c:1224 > #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, = tsdn@entry=3D0x2a2e42c8, usize=3D1536, alignment=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8, is_internal=3Dfalse, arena=3D0x0) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 > #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D1536, = alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 > #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff71e4, = dopts=3D0xffff71c4, tsd=3D0x2a2e4060, size=3D1536, usize=3D1536, = ind=3D) at jemalloc_jemalloc.c:2398 > #20 imalloc_body (sopts=3D0xffff71e4, dopts=3D0xffff71c4, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 > #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff71e4, = dopts=3D, dopts@entry=3D0xffff71c4) at = jemalloc_jemalloc.c:2693 > #22 0x2a15677c in __aligned_alloc (alignment=3D8, size=3D1536) at = jemalloc_jemalloc.c:2821 > #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D8, __size=3D) > at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 > #24 operator_new_aligned_impl (size=3D, alignment=3D8) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 > #25 operator new (size=3D, alignment=3D) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 > #26 0x2631dde0 in allocateBuckets () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:915 > #27 grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:849 > #28 0x2631dd0c in grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:580 > #29 0x2631dd0c in InsertIntoBucketImpl () = from /usr/lib/libprivatellvm.so.19 > #30 0x2631daa4 in InsertIntoBucket () = at /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:590 > #31 FindAndConstruct () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:369 > #32 0x2631d49c in operator[] () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:373 > #33 analyzeBasicBlock () at = /usr/src/contrib/llvm-project/llvm/lib/Analysis/CodeMetrics.cpp:234 > #34 0x28e2c3ec in run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/FunctionSpecializati= on.cpp:643 > #35 0x28f4fd70 in runIPSCCP () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:165 > #36 run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:403 > #37 0x27b85d14 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () > at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 > #38 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 > #39 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 > #40 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 > #41 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 > #42 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 > #43 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 > #44 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 > --Type for more, q to quit, c to continue without paging-- > #45 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= > #46 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 > #47 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 > #48 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 > #49 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 > #50 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 > #51 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 > #52 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 > #53 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 > #54 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 > #55 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 > #56 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 > #57 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 > #58 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 > #59 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 (gdb) list 165 assert(size > 0); 166 if (config_debug) { 167 /* Check the whole first page. */ 168 size_t *p =3D (size_t *)addr; 169 for (size_t i =3D 0; i < PAGE / sizeof(size_t); = i++) { 170 assert(p[i] =3D=3D 0); 171 } (gdb) x /1024x addr 0x2b629000: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b629010: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b629020: 0x00000000 0x00000000 0x00000000 = 0x00000000 . . . 0x2b629c10: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b629c20: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b629c30: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b629c40: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b629c50: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b629c60: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a . . . 0x2b629fd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b629fe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b629ff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb)=20 It has more 0x5a5a5a5a 's after that. > For reference: >=20 > . . . > Building = /usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang/CodeGen/Backen= dUtil.pico > . . . > Building = /usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang/CodeGen/CGDecl= .pico > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" > . . . > _ERROR_CMD=3D'c++ -target armv7-gnueabihf-freebsd16.0 = --sysroot=3D/usr/obj/usr/src-investigation/arm.armv7/tmp = -B/usr/obj/usr/src-investigation/arm.armv7/tmp/usr/bin -fpic -DPIC = -UPIC -O2 -pipe -fno-common = -I/usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang = -I/usr/obj/usr/src-investigation/arm.armv7/lib/clang/libllvm = -I/usr/src-investigation/contrib/llvm-project/clang/lib/Basic = -I/usr/src-investigation/contrib/llvm-project/clang/lib/Driver = -I/usr/src-investigation/contrib/llvm-project/clang/lib/CodeGen = -I/usr/src-investigation/contrib/llvm-project/clang/include = -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER = -I/usr/src-investigation/lib/clang/include = -I/usr/src-investigation/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd16.0-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd16.0\" = -DDEFAULT_SYSROOT=3D\"\" -DLLVM_TARGET_ENABLE_AARCH64 = -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_POWERPC = -DLLVM_TARGET_ENABLE_RISCV -DLLVM_TARGET_ENABLE_X86 = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-format-zero-length = -fstack-protector-strong -Wdate-time -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-parameter = -Wno-error=3Dcast-function-type-mismatch -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments = -fno-exceptions -fno-rtti -gline-tables-only -std=3Dc++17 = -stdlib=3Dlibc++ -c = /usr/src-investigation/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.= cpp -o CodeGen/BackendUtil.pico;' =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 18 19:20:13 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 4d9vZv4w23z6GPMw for ; Tue, 18 Nov 2025 19:20:23 +0000 (UTC) (envelope-from opensource@uitveenendaal.nl) Received: from mailrelay1.mijnmailprovider.nl (mailrelay1.mijnmailprovider.nl [46.235.45.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9vZt35v2z3XYy for ; Tue, 18 Nov 2025 19:20:22 +0000 (UTC) (envelope-from opensource@uitveenendaal.nl) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of opensource@uitveenendaal.nl designates 46.235.45.170 as permitted sender) smtp.mailfrom=opensource@uitveenendaal.nl Received: from mailnode8.webreus.email (unknown [46.235.42.205]) by mailrelay1.mijnmailprovider.nl (Postfix) with ESMTP id F2F393661C for ; Tue, 18 Nov 2025 20:20:13 +0100 (CET) Received: from localhost (unknown [127.0.0.1]) by mailnode8.webreus.email (Postfix) with ESMTP id B548410262D6 for ; Tue, 18 Nov 2025 19:20:13 +0000 (UTC) Received: from mailnode8.webreus.email ([127.0.0.1]) by localhost (mailnode8.webreus.email [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkMT0pCzO3JJ for ; Tue, 18 Nov 2025 20:20:13 +0100 (CET) X-MMP-Auth-Sender: opensource@uitveenendaal.nl Received: from [192.168.88.38] (unknown [45.142.235.164]) (Authenticated sender: opensource@uitveenendaal.nl) by mailnode8.webreus.email (Postfix) with ESMTPA id 95D2C10262A8 for ; Tue, 18 Nov 2025 20:20:13 +0100 (CET) Message-ID: <234ae3a0-eed0-4c33-ad3c-9d5811549562@uitveenendaal.nl> Date: Tue, 18 Nov 2025 20:20:13 +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 Content-Language: en-US To: freebsd-current@FreeBSD.org From: Michael Subject: HP ProBook 6550b hangs on kernels above 14.0-RELEASE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.35 / 15.00]; NEURAL_HAM_SHORT(-0.96)[-0.963]; NEURAL_HAM_MEDIUM(-0.83)[-0.832]; NEURAL_HAM_LONG(-0.26)[-0.257]; R_SPF_ALLOW(-0.20)[+ip4:46.235.45.128/25]; MIME_GOOD(-0.10)[text/plain]; RECEIVED_HELO_LOCALHOST(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:213192, ipnet:46.235.40.0/21, country:NL]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[uitveenendaal.nl]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: 4d9vZt35v2z3XYy Hello, ==== One of my old laptops (HP ProBook 6550b) was running FreeBSD 14.0-RELEASE (amd64) perfectly fine, but upgrading to anything higher results in a boot that hangs at the line: psm0: model Synaptics Touchpad, device ID 0 A while ago I tried upgrading to 14.1-RELEASE and run into this problem. Back then I decided to wait, hoping this glitch would be ironed out in a later release. But today experimenting with 14.3-RELEASE and 15.0-STABLE from 20251113 I got the same results. It would be great to find a fix for this and would like to help troubleshooting this issue. I'm not even close to a kernel developer though, but perfectly capable of gathering all kinds of information (I'm a FreeBSD-user since version 4.4) and help testing. ==== This is what I posted on the FreeBSD forum. The post is here: https://forums.freebsd.org/threads/hp-probook-6550b-not-booting-14-3-release-15-0-stable.100065/ The conclusion there was to try again on this mailing list. I tried kernels 14.1-RELEASE, 14.3-RELEASE, 15.0-STABLE and the most recent version I tested with is FreeBSD-16.0-CURRENT-amd64-20251110-dbb34d496708-281771 The problem is still there. It seems the system locks up since scolling back up doesn't work either. I wonder if anyone is willing to look into this. The offer to help troubleshooting this and test a solution (if any) stands. Kind regards, Michael From nobody Tue Nov 18 21:44:59 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 4d9yp84Zq8z6Gcr4 for ; Tue, 18 Nov 2025 21:45:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 4d9yp75kFDz3s71 for ; Tue, 18 Nov 2025 21:45:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=g3ZcnmbF; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763502313; bh=EeBGvWW38SxJVgTZeMAqLi4x/Kf1p3ck0jbz9cmP3uY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=g3ZcnmbFmcHm2ilvRRzAF6ciCXmY9muJU9e2b1osUIC2fZD3jcbDt4Wuh7G5AM9OHB+LJwqIAdeAE3GOJl5Xj3pUrnYksIrFlSuHn2mMvjWVjBOk96iBMoBL6RxYubOc2N57bVsLmr6s1ukAKb2tKX0HDv/6H4qBrkjrsuQJnqD9VNqdfpbkyGyoIYevs5pCyQ7kFnRKWs/vpztyg/Ev74Vs+Sy5pgeQILUWuptBeENJC/75sLayWYKFzBow+FHj0V/Xdsd96Qn1A5DS/pmNAxnVExpPXJ8ZuX9/szQTwJR9Wpg6RhhPMWh5AIjjS+NXi8ubkYmFxzUrWa9CBi9cgg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763502313; bh=2iLoZ71j2i8bpnmwM6uRCw+6B51KwtlhNFIOeW016gR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TZuma4dkTIEIjMAfgXVeKvsDK9hBMbb7T302JImGIY6MQ4dDID98HoGgPCE/3M4ZZtYnzHMs6ZRm7Id7iv3OfGxrAH18cMNIA4s7vI5ejg7xZhUMHCqOw+7KZdQvbCVLxSdBDy/jOVZ4mJlUIrBB7JwGv4tAYs5tF3xkBmjXfcSO1WGmgGKdIgUAwqyJ0DjUEdzMPsudrOc4xr0FyiY36pUfEskv7kQkA012tqU2nwZ8ULHYn4W2hOccYJ4O6jl5O83q8DbmyGlHbUHmdbEU1Komzza57KKaZ5anG0aTCTJrkd/jyhkAjW9o1Ww+ktjalWsqz+IKLWIMpZDb+hKZpg== X-YMail-OSG: 1VNreWcVM1nLNXJR6pZksI2E.f8_avif7Us2ADVRRChXq5Xs51k7jUsdXR2U79n O_jdyn1JecVu0icZmeBEY6jfr94uvLyVOAK61lX0gZ826WsOn_cpPj1GOWEiVp57Qd2Q.c4Ia6D. rJGgDLffLxJDxfOqBW9sJ6rsonXh.3S.EQnYlJ3ZIAf.6K9KfTi9B3KGvBCnURcS0D25YV3CmWyZ dIDhZ3UXBLvkLIWvdbtJqWyDXvn6mIn4mbkfAiCIjtD75WerKF4tZzTt3j1bgBmQuyjeyUJcbiPP IXgva5iFcFodPGa3018oxecuf02yRXrZBhBelVM8.VluvxJkLik8I518dgeelJOcLCOhoQUld5MW 5uCG1atrFv.uNt689SBSgICGUVNoLsUQRUfH5d_HlaK2sNDJq7lRKE22aVeq9LyV3pWT3EsckOt. 69wvbiXuNHW8BJVGUq3sIjQ9bGTS5dOswbQX7ZrZvquQt49pvXxSRsFnnW1R36yK6uduwkLCJgj. ATaFhTOO4qM6VFrs4LQLgNOH_Z_qq7ppWLlXhFmUcbhnNHE0CP1Lg..wOcl71TlEqrRc7ZrPK_hp s9nLJxdqtTNJI1S2o_bLfVTseqtHj4jCM3Ysw664zUxYbLIG80nXpH7.pU1hEO34nZcdcEzWLvkv 0qQ8EVlOUe.ZT262k4524cCv9APS3agrq5ltnZb9F84xh3xUKPhkkoQHzAG4izC_SOQ9xdnEouqp G7m7dofOSCyC5qzsC7KcKnEylUgZ0YvnuNxiw1AI6fFkVlE4yiSsy.3fHXNkZe2R4b8JUVtEbcsW ge3usykjI2dRLqD4S0pzYGUBztOoGZaaeik_IapO.xwKCFM0K8DpsEWemEX0CvKvDXim.LoXZS4d .CmJG5dNEVGWtQW.1D3fvKNNWXbBE3GR8NNEtHLyCv7aZLQUfVEc3qvYEGDKOh5dnoJqWWBf4B8Q OT01e8EULu3TsiJAdLUDoSALZ_MVN_loMVIeTXvhx6ZIx3XnmWuR2psjO7tDyZSHSWUhhkA.80lR OkqXwDknyRJnsWeCoDKUH6gUxGNkKTdPRuHCA52ab9d1CEjrJ92oZi_lkleR8vfX1VHQBGlfWJur 0USjSkuZ6RE7Y1uAguvyQ.eRAvlGlXQbJpEv3Ii_B3.6WVz5VYTjTG4Q_Vhz4omFn.PBWm.Ew_BX .sH97h575VBAjAt1r9CZHvNaq7D1Cx8f38PHsTNNMLUTba_nXcZdVeExcmVkTnCsbhWyNfqTdJ6Z Jg0AqCXO3k2KibGwTnGsG_gh30H45wvTerwB54FFrT.RyO7oamrPZ4kxI7qTvf.uugjEnTOXLXK1 6S5KEJ_gMZD1p4e7k61wGBIQ5HWB0ariccw_xEIOoeeFS_2dnp_IODt4zBBQxgLRt9.OhWEWDuJJ Inarpge.FlD.N_ZB2CEo6dKhNxCLzGbuY.j40glUyzS11GelaBch3QRlC2D96.7bQilO2i1Zbb_F RIOoOQSBaxQQvUkydXiSYZE4dICvsfMMY5SVcAA2hjNbCgYbNF5SwL2hZPnndTHcdz65s.sIojWZ SKXO0_dRWTM0cWWeRGdWOTz6Ha7S.jF2K1hsDprmfiHqzw.8kxgBrLXeSU_5wjObiIXJspcHcumq 0NHKQRHLG0cVc2Ds_VTqj73v2K9Re46VTFeyI.PpIOs1q103M5yfl.tR9VxUMIXq63QAnLyWIaMH HvG3coWAAyAC1shMqUW2RDErnxBV562rxl.M.LVtpUGrQeGHmo6ZQqmlgGdPLvZ5kVYJuJo4DkG3 2QptqGLIhn7ednPA1z76iSFHRXqsrFt9rxGILuVIPu1fwo.WGUM.5nd0qDwjU0VxZp71o.KcK_rG 4pIREeIlKCLIwK0pugTTVnwjAO7qZ5BrWK40ILmOgQYXgQwUJUF8FyyBTrmr44b5i9h4eNDjGgiO lIaK6aNw5Uac7rBooPWRo7XnJTMqzilroph743gSmGFpx.yemjp9kpEdsL2VH1uS_TZk7X_5wxcg NutRJAXF4pTNuKm5_uwIxX5KZaFr._mCpvgjsofUPGRhRAGUtVfx1Ip92vybe7NjgTTug77qiRbK _N0MN.i.vYXJN4jwyPExEBGr7FS.l_qL.MRP1SiRP9LCgNifa0pE0TPqWqfCJKE4Wq4eSBvxVaMA wqdP1o3MXElIr4PldDphNi6kypXcEgOcNQ5GvNmb_QxElIFm.uhFbLPT6FKrQzQYNpmAfBFJUQwY Ag6P9VW34QMk.bbOmCbV1.nKvV.SvuN_zCK4cskhBMn_q7A6viQk4FcWw7Sd0.thAdTa2ZlHRsNL OgNZZlBqYbnwMseLInoQo X-Sonic-MF: X-Sonic-ID: b3870573-84cf-4688-ae24-7ffa77eea970 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Nov 2025 21:45:13 +0000 Received: by hermes--production-gq1-67d9c848cc-686tn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d8d983cc13f055bf23cc6df39aaea144; Tue, 18 Nov 2025 21:45:11 +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 [gdb backtrace! End of area has 0x5a5a5a5a sequence] From: Mark Millard In-Reply-To: Date: Tue, 18 Nov 2025 13:44:59 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.919]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_HAS_EXCLAIM(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from] X-Rspamd-Queue-Id: 4d9yp75kFDz3s71 [I got another little block of time again and have a little more information.] On Nov 18, 2025, at 10:39, Mark Millard wrote: > On Nov 18, 2025, at 10:18, Mark Millard wrote: >=20 >> I modified system clang to not register its 2 SIGABRT handlers. >>=20 >> The backtrace has the jemalloc call stack activity as well. >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 >> #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 >> #3 0x2a196128 in ehooks_debug_zero_check = (addr=3Daddr@entry=3D0x2b629000, size=3Dsize@entry=3D12288) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 >> #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080,= new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff6f17, commit=3D) >> at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 >> #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D12288, alignment=3D4096, zero=3Dtrue, commit=3D0xffff6f77,=20 >> growing_retained=3D) at jemalloc_extent.c:1003 >> #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 >> expand_edata=3D0x0, size=3D12288, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 >> #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D12288, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 >> #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D12288, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 >> deferred_work_generated=3D) at jemalloc_pac.c:178 >> #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, = size=3D12288, alignment=3D2147483615, zero=3D, = guarded=3Dfalse, frequent_reuse=3Dtrue, = deferred_work_generated=3D) >> at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 >> #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D12288, alignment=3D, slab=3Dtrue, szind=3D25, zero=3D, guarded=3Dfalse,=20= >> deferred_work_generated=3D0xffff703f) at jemalloc_pa.c:139 >> #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D25, binshard=3D0, bin_info=3D0x2a21ff0c = <__je_bin_infos+1200>) at jemalloc_arena.c:839 >> #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4528, = cache_bin_info=3D0x2a6004f2, binind=3D25, nfill=3D5) at = jemalloc_arena.c:1034 >> #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4528, binind=3D25,=20 >> tcache_success=3D0xffff70ef) at jemalloc_tcache.c:238 >> #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D25, zero=3Dfalse, slow_path=3Dtrue) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 >> #15 arena_malloc (tsdn=3D, arena=3D, = size=3D1536, ind=3D25, zero=3Dfalse, tcache=3D0x2a2e42c8, = slow_path=3Dtrue) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 >> #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D, usize=3D, usize@entry=3D1536, alignment=3Dalignment@entry=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8) >> at jemalloc_arena.c:1224 >> #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, = tsdn@entry=3D0x2a2e42c8, usize=3D1536, alignment=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8, is_internal=3Dfalse, arena=3D0x0) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 >> #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D1536, = alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 >> #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff71e4, = dopts=3D0xffff71c4, tsd=3D0x2a2e4060, size=3D1536, usize=3D1536, = ind=3D) at jemalloc_jemalloc.c:2398 >> #20 imalloc_body (sopts=3D0xffff71e4, dopts=3D0xffff71c4, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 >> #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff71e4, = dopts=3D, dopts@entry=3D0xffff71c4) at = jemalloc_jemalloc.c:2693 >> #22 0x2a15677c in __aligned_alloc (alignment=3D8, size=3D1536) at = jemalloc_jemalloc.c:2821 >> #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D8, __size=3D) >> at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 >> #24 operator_new_aligned_impl (size=3D, alignment=3D8) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 >> #25 operator new (size=3D, alignment=3D) at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 >> #26 0x2631dde0 in allocateBuckets () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:915 >> #27 grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:849 >> #28 0x2631dd0c in grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:580 >> #29 0x2631dd0c in InsertIntoBucketImpl () = from /usr/lib/libprivatellvm.so.19 >> #30 0x2631daa4 in InsertIntoBucket () = at /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:590 >> #31 FindAndConstruct () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:369 >> #32 0x2631d49c in operator[] () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:373 >> #33 analyzeBasicBlock () at = /usr/src/contrib/llvm-project/llvm/lib/Analysis/CodeMetrics.cpp:234 >> #34 0x28e2c3ec in run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/FunctionSpecializati= on.cpp:643 >> #35 0x28f4fd70 in runIPSCCP () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:165 >> #36 run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:403 >> #37 0x27b85d14 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () >> at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 >> #38 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 >> #39 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 >> #40 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 >> #41 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 >> #42 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 >> #43 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 >> #44 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 >> --Type for more, q to quit, c to continue without paging-- >> #45 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= >> #46 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 >> #47 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 >> #48 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 >> #49 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 >> #50 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 >> #51 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 >> #52 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 >> #53 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 >> #54 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 >> #55 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 >> #56 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 >> #57 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 >> #58 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 >> #59 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 >=20 > (gdb) list > 165 assert(size > 0); > 166 if (config_debug) { > 167 /* Check the whole first page. */ > 168 size_t *p =3D (size_t *)addr; > 169 for (size_t i =3D 0; i < PAGE / sizeof(size_t); i++) { > 170 assert(p[i] =3D=3D 0); > 171 } >=20 > (gdb) x /1024x addr > 0x2b629000: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2b629010: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2b629020: 0x00000000 0x00000000 0x00000000 0x00000000 > . . . > 0x2b629c10: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2b629c20: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2b629c30: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2b629c40: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2b629c50: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2b629c60: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > . . . > 0x2b629fd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2b629fe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2b629ff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > (gdb)=20 >=20 > It has more 0x5a5a5a5a 's after that. =0D The backtrace indicates 3 pages (12288 Bytes, 3072 size_t's) at the __je_pa_alloc call. So looking around the beginning and end: Beginning (and somewhat before): . . . 0x2b628fc0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b628fd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b628fe0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b628ff0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 (gdb) x /1024x ((size_t*)addr) 0x2b629000: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b629010: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b629020: 0x00000000 0x00000000 0x00000000 = 0x00000000 . . . End (and just after): . . . 0x2b62bfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b62bfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b62bff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb) x /1024x ((size_t*)addr)+3072 0x2b62c000: Cannot access memory at address 0x2b62c000 For reference: static inline void * ehooks_alloc(tsdn_t *tsdn, ehooks_t *ehooks, void *new_addr, size_t = size, size_t alignment, bool *zero, bool *commit) { bool orig_zero =3D *zero; void *ret; extent_hooks_t *extent_hooks =3D = ehooks_get_extent_hooks_ptr(ehooks); if (extent_hooks =3D=3D &ehooks_default_extent_hooks) { ret =3D ehooks_default_alloc_impl(tsdn, new_addr, size, alignment, zero, commit, ehooks_ind_get(ehooks)); } else { ehooks_pre_reentrancy(tsdn); ret =3D extent_hooks->alloc(extent_hooks, new_addr, = size, alignment, zero, commit, ehooks_ind_get(ehooks)); ehooks_post_reentrancy(tsdn); } assert(new_addr =3D=3D NULL || ret =3D=3D NULL || new_addr =3D=3D = ret); assert(!orig_zero || *zero); if (*zero && ret !=3D NULL) { ehooks_debug_zero_check(ret, size); } return ret; } extent_hooks is optimized out so I do not know the status for the ehooks_default_alloc_impl vs. the tsd_pre_reentrancy and extent_hooks->alloc and ehooks_post_reentrancy usage that actually occurred. __je_extent_alloc_wrapper's context can be used to find that *zero was true when ehooks_alloc was called. It had to be true as of the ehooks_debug_zero_check call. Nothing suggests a smaller size was involved at any point. It looks like ehooks_default_alloc_impl or extent_hooks->alloc (whichever it was) just did not produce the correct content. Nothing yet stands out to me as looking likely to be somehow armv7 specific. Looking at: void * ehooks_default_alloc_impl(tsdn_t *tsdn, void *new_addr, size_t size, size_t alignment, bool *zero, bool *commit, unsigned arena_ind) { arena_t *arena =3D arena_get(tsdn, arena_ind, false); /* NULL arena indicates arena_create. */ assert(arena !=3D NULL || alignment =3D=3D HUGEPAGE); dss_prec_t dss =3D (arena =3D=3D NULL) ? dss_prec_disabled : (dss_prec_t)atomic_load_u(&arena->dss_prec, ATOMIC_RELAXED); void *ret =3D extent_alloc_core(tsdn, arena, new_addr, size, = alignment, zero, commit, dss); if (have_madvise_huge && ret) { pages_set_thp_state(ret, size); } return ret; } can get into atomic handling: atomic_load_u for ATOMIC_RELAXED is used. extent_alloc_dss vs. extent_alloc_mmap ends up involved via extent_alloc_core if ehooks_default_alloc_impl was used. I do not see that I can pull out much more based on my lack of familiarity. >> For reference: >>=20 >> . . . >> Building = /usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang/CodeGen/Backen= dUtil.pico >> . . . >> Building = /usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang/CodeGen/CGDecl= .pico >> : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" >> . . . >> _ERROR_CMD=3D'c++ -target armv7-gnueabihf-freebsd16.0 = --sysroot=3D/usr/obj/usr/src-investigation/arm.armv7/tmp = -B/usr/obj/usr/src-investigation/arm.armv7/tmp/usr/bin -fpic -DPIC = -UPIC -O2 -pipe -fno-common = -I/usr/obj/usr/src-investigation/arm.armv7/lib/clang/libclang = -I/usr/obj/usr/src-investigation/arm.armv7/lib/clang/libllvm = -I/usr/src-investigation/contrib/llvm-project/clang/lib/Basic = -I/usr/src-investigation/contrib/llvm-project/clang/lib/Driver = -I/usr/src-investigation/contrib/llvm-project/clang/lib/CodeGen = -I/usr/src-investigation/contrib/llvm-project/clang/include = -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER = -I/usr/src-investigation/lib/clang/include = -I/usr/src-investigation/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd16.0-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd16.0\" = -DDEFAULT_SYSROOT=3D\"\" -DLLVM_TARGET_ENABLE_AARCH64 = -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_POWERPC = -DLLVM_TARGET_ENABLE_RISCV -DLLVM_TARGET_ENABLE_X86 = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-format-zero-length = -fstack-protector-strong -Wdate-time -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-parameter = -Wno-error=3Dcast-function-type-mismatch -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments = -fno-exceptions -fno-rtti -gline-tables-only -std=3Dc++17 = -stdlib=3Dlibc++ -c = /usr/src-investigation/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.= cpp -o CodeGen/BackendUtil.pico;' =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 00:29:08 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 4dB2Rb4GG5z6GsLk for ; Wed, 19 Nov 2025 00:29:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4dB2RY4ygzz46RW for ; Wed, 19 Nov 2025 00:29:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=t+HM4VnW; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763512166; bh=GznQXr6ekAQk3ry/LhyAPGJkHcX2J0pZ+q0XAwaxJVE=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=t+HM4VnWoBgqa8gTEWTi32g3SN3P1C2x/xaoOY2/aYKqK3SnI2PpN3/rgj9mYEy/UDZUquT1kPJSCwD/nvLvl4LJeT7TI/BIiqo8n06+fqAWt0y37mSfWoVkXJTZHQ1DCL22FrSRhQW6vD5+mOVQIhoT1WS/8kZZ+DCh7GcGs2UYU5/yX87LWL9BdE3Hkk0yx2baWQtY0X7i4guAvFJPjZU06YZMdzZlplKJwneDOyTjzdT+15chodcfEiDVWDTkyGpzXndWKebpvYos7IMyjogNJwErBTAZQZqJKgkYih4fxsb8LENgxXvKhgsOfbppgxTyzgbeH9OqdkDEzo0Y4Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763512166; bh=VS5HNmQR5S0OH0mwEHPYihGdSz/QxKVBf3ach7qzATs=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kMwHZF4MljaDzBpmTzOrSR+NRXFFbj/bTODarWmXH4eZqw/y1xeq0suIeowtbXv/+IU7BnAfZPwVOlW46zd3SZa52oAS8jz07cCBiWDgbLP/ZxvhLIYeTqXkQTKDSKtpuL+oX74UkIyHzjX8phkqsRwU2cj39DtcaQAx5+aWceTQHc/xFdCpMw8kpCjAo0e9Rm+aUlhiIkxleLsedtICYsQ4ol0Y3cXt7zYqqgrluYrcB1D2J+2+C0Qx2eEni/k/kOnya3UXoW+OmvejFTz3KFRfYUO/oruyDmFpckLBjQbCvzxhXyiOqbeu+51y/leBsY/bIMhaH8OVnByPXWUwGA== X-YMail-OSG: fIHO6cUVM1mVYuNOWvkIFg5min.Mspfwxo3CVXdWKeCfMfGrsXJwwttGN9MgA7x 5EFRvr.6ucIrbzt.sJ4TZOovUJowhXf2TjTpJZEHG3gkxQoiUsswosKsSLgZDJWaYJVhRRbnUMP4 Pw2Ggu2d9sO92sTlXN8whYx2yn3LsK7nebrOjjLv88Qlyq1RdP3jda2LmJ5YBobn6D2dR4f0SjQI 042dBlXVI29mOo_zFUB95oFutrMhpm84duT8A9oFqaSAUFhhdSo4bLsdXaeDouDsTDhbCwtwoRbC YMVGDXKJBWcdOg.IhCnsccKQSqBisurNm7Kj8Uu6DSRCYDKUatsYGXVEIMzzQiCfs4fLBPaDps0k y4GItsydej2apwr9jgGPM1TFKYiwKuMSUBUodN7LXYkoDYICGrlkmDyXvYDbYHjomoh6xbEYDokx NHsyCmQ0OOkOvHocTwCa.PvGenQeT2SuRy2EX94nh5tV9e9lcK5PLpgM_2JtPLcIgbZ095OBHU7U eSuwNndakkFbPOXILWdKIfWPSzhf8boeJSWN5E7yHeSM6EjNPnHql.2yOt.qUyYEWDp9EqEEx6CP LAb1w2LAD2HHHNRaS9nnj526OfFbWAvQfmnlzfH4b4CAQIEoZhx4.aUcboXzTly3qVwhjluck_w7 w_trCBQoLvOZJXxm2T2Efe1iICf95CBY.n2vchmyfabNqJXNN0GT9riwZX88gvjqaXSdVF6AGAyo Rl1c15hhbvt5PBodhSZrk1q_6M_b4O8ynLwtrYwkeSrQqUJ_fNSeVIGhYkAeWvesZ1TtGvJr4SEk 0odDQBSxfdixeT5_7xb2v.xCRkBPoPb1BQT7rNMdvYcDTSYe7.D1pwqPCYLaSgS5.bqHWECiAQYq ZduTMcQE4bdpEqvKWepsI0igTwxYlbOWDYfxxHYbr_aYqHi.nxZOeLkkCt3hJi7kwOBMyug.bUcK MKSt.xS1jCLzyOS06Icvy6yIswTRMvkraL35TGIUWrsmq4mRp9A9x72FHKUCyHIGfsAivl6gxLa1 lqBb6If3n45Kx6lWTaZT77bxJQ9IwQq6N7LezEYdKxXD518XB3oDMjCwCTR1kK2_hwjd9sAz0NSv 0qjeu8P391vphkfhCJJlP_2ppFrKI.tXzP1awB0GDo293whLOTxGLzm_BBmIOJNljTjTv72bRqTV 8Lj.SUvl20ECG0BXHN5Zpdt9SbhbR.QiqEJDKkB0A76BZXmMqjzQW42MDFJpvDc326Fb8huAuzcA rZIbT7X8NFCRTnR9j.TeA5_qFg4OQo1r84lslspuiJM_rNEGW8AmD20P9seJogbSsC3wxr20p6nz kvs6N5wlqHw.S_ycml9TXWr8xWMkuXgCmLeQNd4EcnpnBp9Hv.WBbQUyN_K0XDHmUxbPJcouhQsm TpyKPqZM5XxxR90.vzZX95hA2zbm45DG.my3.RUBGGhxKKilF3MH0bO144k1OTHBv0c2cM81Sphw 24sEGNMgzTJDMYKmVNWB2ujDdNp4ZYRouZuOjAAkJIEPzXDVHKZzWkjLZ1edtw4.TLzVVyoc48uL IZepia4BWEriJhg8Ghxupsrx0o_7H5NSxT76YeDcwQSC.VK6G1AGK9XuReJL0M2L4GfSmJkyqQAy tzwc.70LbgDclQFkRvZ9_EA4BnM86dllaOwonhHZ7WH_O1JdRvn1Qf4.h6Y7Pin59XhJ.CcxK1jp eK6tcbnYa_gyvxFLNrjyj970PKz6uJ6NC2ZCubgshpYA_oiuSrw9MNmbHSIcldAjLWq9KfwPeJ5y usqfZH.eZHPGzdZkYdzmEk3sAtUVPGHgepDGv8t1.i5C2KfujkWTXbGoZsIUvj6qmzHvvRDmB_67 l1VU1I2YNg_MsqWv0E6HGCV7VYOj1a.D27Y5OVLWsyaS3XNKSweKMBwrOpUf8E_4qytVsKgr325b NxnnvQ8lVBk9CLwdKWqqgm89aj5unGppGxG7KiwOAPcwjPOMsgz6hyVn1K6yjQzMQEYr23hAgCAB aXHfTiVDTyS1qnVObrBuFTjXT_icq7uHdwNqw0zZq9a1tbeJBYLjbdeY8d0ZBn6fRqHKr__P22gR FFvcTr.hAhTDIIvkMs4GH_7JR3KqTa7YIN8XADzfAeLoBw5JcimnlBqJhFeIJ1qC1c9WUu5iUzLD wP1AAc46vx5Ovh2VDgt5WW30wr_xBc.vCmGPtdCiwCnYCuc8mguf4ynliUGl2xBavNlxWMBiTZBS UOLXYlfaGEK1ZJZeU13In7_NKb_qeT28yZ9cBwC05wEyEKZ7GdjrqO_v.c7cgvv3hWqc_DG_bV1N nnqlwH5frVg-- X-Sonic-MF: X-Sonic-ID: 47ee7648-86a6-41c0-aa0b-47c80ff043f8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 00:29:26 +0000 Received: by hermes--production-gq1-67d9c848cc-c9zv9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7bc963dadc66a5aa550c80f452865f11; Wed, 19 Nov 2025 00:29:19 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #1] Date: Tue, 18 Nov 2025 16:29:08 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.48)[-0.479]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4dB2RY4ygzz46RW I'm only sending notes from testing of how similar other failures appear to the 2 lists. Folks can ask that I do otherwise for them if they want. This one is for size 4096 (1 page). It looks like #0..#15 are similar to the original report but #16 is not. #15 is for: arena_malloc (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2a80d000,= size=3Dsize@entry=3D4096) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff7b87, commit=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D4096, alignment=3D4096, zero=3Dtrue, commit=3D0xffff7be7,=20 growing_retained=3D) at jemalloc_extent.c:1003 #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 expand_edata=3D0x0, size=3D4096, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D4096, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D4096, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 deferred_work_generated=3D) at jemalloc_pac.c:178 #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D4096, = alignment=3D2147483615, zero=3D, guarded=3Dfalse, = frequent_reuse=3Dtrue, deferred_work_generated=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D4096, alignment=3D, slab=3Dtrue, szind=3D1, zero=3D, guarded=3Dfalse,=20= deferred_work_generated=3D0xffff7caf) at jemalloc_pa.c:139 #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D1, binshard=3D0, bin_info=3D0x2a21fa8c = <__je_bin_infos+48>) at jemalloc_arena.c:839 #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e42e8, = cache_bin_info=3D0x2a6004c2, binind=3D1, nfill=3D100) at = jemalloc_arena.c:1034 #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e42e8, binind=3D1,=20 tcache_success=3D0xffff7d5f) at jemalloc_tcache.c:238 #14 0x2a15e538 in tcache_alloc_small (tsd=3D0x2a2e4060, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D16, binind=3D1, = zero=3Dfalse, slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 #15 arena_malloc (tsdn=3D, arena=3D, = size=3D, ind=3D, zero=3D, = tcache=3D, slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 #16 iallocztm (tsdn=3Dtsdn@entry=3D0x2a2e4060, size=3D, = size@entry=3D16, ind=3Dind@entry=3D1, zero=3Dfalse, tcache=3D0x2a2e42c8, = is_internal=3Dfalse, arena=3D0x0, slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:55 #17 0x2a164df4 in imalloc_no_sample (sopts=3D0xffff7dfc, = dopts=3D0xffff7ddc, tsd=3D0x2a2e4060, size=3D16, usize=3D16, = ind=3D) at jemalloc_jemalloc.c:2402 #18 imalloc_body (sopts=3D0xffff7dfc, dopts=3D0xffff7ddc, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 #19 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff7dfc, = dopts=3D, dopts@entry=3D0xffff7ddc) at = jemalloc_jemalloc.c:2693 #20 0x2a156000 in __je_malloc_default (size=3D16) at = jemalloc_jemalloc.c:2726 #21 0x29e61990 in operator_new_impl (size=3D16) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:34 #22 operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:47 #23 0x27e101d0 in __libcpp_operator_new () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/new:265 #24 __libcpp_allocate () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/new:289 #25 allocate () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__memory/allocator.h:118= #26 __allocate_at_least > () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__memory/allocate_at_lea= st.h:41 #27 __init () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/string:2336 #28 basic_string () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/string:1078 #29 str () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/StringRef.h:217 #30 str () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Twine.cpp:29 #31 0x294076d0 in SetNamePrefix () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:502 #32 visit () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:2734 #33 0x293f4938 in rewritePartition () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:4893 #34 splitAlloca () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5284 #35 0x293f04ec in runOnAlloca () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5485 #36 0x293ebfc0 in runSROA () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5596 #37 0x293eba80 in run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5637 #38 0x27b9b32c in llvm::detail::PassModel>::run(llvm::Function&, = llvm::AnalysisManager&) () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 #39 0x276eef80 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 #40 0x2217fd38 in llvm::detail::PassModel>, = llvm::AnalysisManager>::run(llvm::Function&, = llvm::AnalysisManager&) () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 #41 0x276f30e4 in run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/PassManager.cpp:124 #42 0x22178b88 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 #43 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 #44 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 #45 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 --Type for more, q to quit, c to continue without paging-- #46 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 #47 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 #48 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 #49 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 #50 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= #51 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 #52 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 #53 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 #54 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #55 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #56 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 #57 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #58 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 #59 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #60 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 #61 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 #62 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 #63 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 #64 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 0x2a80cfd0: 0x000013f2 0x00000079 0xffffffff = 0xa5a5a5a5 0x2a80cfe0: 0xffffffff 0xa5a5a5a5 0xffffffff = 0xa5a5a5a5 0x2a80cff0: 0x000014a6 0x00000079 0xffffffff = 0xa5a5a5a5 (gdb) x /1024x (size_t*)addr 0x2a80d000: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2a80d010: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2a80d020: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a . . . 0x2a80dfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2a80dfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2a80dff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb) x /1024x ((size_t*)addr)+1024 0x2a80e000: 0x00000051 0x00000002 0x29e862b8 = 0xa5a5a5a5 0x2a80e010: 0x7273752f 0x6372732f 0x766e692d = 0x69747365 0x2a80e020: 0x69746167 0x6c2f6e6f 0x632f6269 = 0x676e616c 0x2a80e030: 0x636e692f 0x6564756c 0x745f5f2f = 0x5f657079 So: All of the page was 0x5a5a5a5a repeated. Before and after had some other values and were accessible. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 01:05:51 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 4dB3Fy3kM4z6Gw2T for ; Wed, 19 Nov 2025 01:06:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4dB3Fw6pZpz3DjN for ; Wed, 19 Nov 2025 01:06:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=M3rtojrc; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763514368; bh=iFD6klO9FUafAP+E+TplYXXOEckJrv4O/RY3+rBiEms=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=M3rtojrcZpq7WUTQtgQqHzxReNmXnjnoW9aqrH74SCzDw16mBAFEXsNC/AjcCQlg2kC7GyRsUB5Rhx3aoLe19Ls70smE1K110l5up1xYexc176h7BUNQeme5L+27SNuAdatiJOZ5kSZc3AGbk8SY5d/q0l0EdBva7IszjFFpja3WpFUdmEgxy7tgdHIRfXtvuUuupCGvp5k+3WyZtekbHwN5V2UD2IF14gMHBo3AR+NOhfu9suKzwk8U0v25JSD0s/yBq4QNT03OfQ2VPte507vsmNDEZWumFOFHYrg6W6bkdNOJMk3HsisdbtRuD4k/aN0qGw8KEHlyw5/QghdljA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763514368; bh=+uBYXgCJ+X5qv3f53c/8bXPdV9xJOUdqm9sbEyzugcM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=gMU74YhIDTNYQNbi91kJEj2OFoObPHF85OW+2qN1ciG68csLbYRAMZ4NW9LzIoYW1MU/dfy51vcCDvQEMlddKr0kM5ZfjRXwyfrxd3Y/n/1spLdzV9nOd6h+eFmLve8kljG+Y3e9cy+HtVK5A6GTHUl2xLK33kiF69pudJ6HeaKn+A4UEjpSYEPMSQCuNyuTBELer1a8fUU1QA/5AS/QGBW3+XiyBbjy7/Ap8r2Pz4Mbtje6Vhg1F0LiIT/naxtLaMx8ksTLjJFIAurybXSGHLCRFoe4XMawFTmFoudz/bO98noo7KqQ96AmZqdLQay1Y/998RrsvHqF+pOAErWmkA== X-YMail-OSG: D67jmvYVM1l6HS2Yn6Ca1FJacw.x9k3iHMyk.gq4HobKiS1cxaOTycFl_bqD3Wc 8L1twYtXexW69nu31_RP52byDN7c1gAy0Xw8Jg.ecv9zcLvutnZYNFHfLvj1FLzQ8TkXflDwZDsZ aFT4_bLOCq0Sd1vImh5uB34xXr50qNYpLNsOhDtKXkftitsodX9hRNR5fEeyhxPg99CsAVrHtbHF UfyYEkpV_7sIAxMMwZHqsgkJFSpdVIZdCOYEiRDPLzVZhNR5mi_vhGE1bLgsAxgglPl0PqwlJ8gy VmfVPiiPw.Oj_3RO_H_rcCxEp_KH8Ce_ZFmFc_4n0Tg4pVexnQHhEbZo_ieNW.BNt2NJRE._zy78 oaoWZo7xLtU.MInICUiy1bnxzsSBqBlIm6x_KXYSQnLWjp2s1ujcKeEVApexZzdGi6xbryD4rnyl q3zazin9vL.LJfAHi6Gig95A3WXHk0E0NrE.F78fvkPzw3LOjYvjwh.SGI.Wa9lDwLDiNwUM8TID ucD8eW0wQKDBURinireENNTvXZdZNe9NBV1dASFT2jkd_fjf4f1n3HOrqsoqg.uJ2zAGirYTsLpn Td9VbvWQUDnuuYvqSHlOMdMY77becV4YxhdWtipvLjeaNmirKxO32wt2U0_fmotxN7GcBg4T6e5E XMNiWHGXi.mmi223FEoKy8x5RV0ywBX1qH1pZJobIgKYqyYZq.FfPpnNBitxUPypZ0yrZfNMJRW2 fFJmXDtAzAT2Xfoor5YiXsRLr9EwAs61GPJyvtGXwn5GbKO5ziZVqL0vCSjQW.is_R90d1gpLR2a vB4Q8q6tumScOKBpWqd7VgtCijJ8IVQKmX5gJjgU8Y3R3E_feko9.BOywAsj0__b_2oRnghMAr0Y rOyKkSCQ8msFIHLiVRdBlqHqIjuJ9DhP0xFua03ka9uFdExL8hrMoK7HHzyT1ZjLYnvr4x3vWsn. vaj59IQmJZxpdxRjQXEDvfjo3UP82Bw6tH2DoBaO1uP6h3UrkOlaex4S914OhWEA4thI42AsCDDF vqHPbo4UpuWYXn.iwSoWv6fSuiESmLJaUbbIArFqyq52vstxECqQ1jqYaKbIoUn3aOSbrIMfmcdS ZohN.d3TC0AlHObdL5zYF2trK6I8mTijNI_JqlRYm1Sf6WwWgRAiERjo.Ut9qOHd5Rvj736FnQx7 reJQ_8lMJfvBO_Zo8l6bZ37WY9GHMYhmTxzXoPHh.VQQ3SvHxNh8xUT7T6dVrBp03r3fND5ovbxF LJPr5MqUrt3kDGGKZ.s__YfNcmPKYI7S03fVf14ntDKpSEpyHh.pJR1bpNvHrKPU33MspFhHr7Tt Zg1XktLpEfgbO3MdbBLPpR.q.r4cgW5KVrum2wgbmCPrWK2X4TOhbtwmaK4n4y7H0HOPbr6NZgp6 Jq.UGA6RY99__askb5IZ4glVnlqSMmVZO7M1X1XQF0dfTxPQroYD8FDkLn1Jy3cMIyVG5ciVAfdJ k0VXfw185WYsHbLKHmsjHY74sdFrr4Z.gJIXcOzQiuuC.xndNgpzfdkMMN97N46B9VhmoQnGb1mk _xAgovxOG0rk8gMo7GCshWvt7dB4fhyV1j0GYVZY.NPNXPgy1kEUq0k3SkPwJuCz368bdAYa1IeT wzPWsRxLYQLgBImdoI476uS7qxJqXdZGSRzvloaxkmdDRo5xhwz6cuW4.FXSSvebzg0qohBt5mdf XaCqKzmuGzSTvcThPy3TqzkQzoFkNLgOwsDqAe_jjVVMfCVwitnYbm51ct1LKoxY9L03VCtKMBr4 N4w2wKBEGq3Fl8Afc7XuKI9nTSMzCUh_lTt.IN52drjMe3M5vK8QiG0t9afg_XKvCZyVu2ihryet xX4sB9hRn4mHGDkLvPi6.EgNBdYpPn6IjzAt3OoLJfg4c_Dk6fnmZzStrHAbPBcTCDjdxtqDQmG1 LLBk9wGcRwQYW_URXk6bzxSfbFBwXldsaSxfS04D_vcedTuOL58THLQ5RlUPoEOQrIh4tLrLB6ZP eq7fEj0xH7sYhlYgvsrV0Arl0Q_J1vCPIZHXa8j5l9JS9feR0B9iW.YgKORY.qjTeq18t.uuSHNz J5KzD1E_V_uyaGrOZ2jtQwqNn9r0EfdTazVcCoQF3EcdoLEcAEIWl6OeBPdvE1BrN5Qhru6Kml6A pxZilkJmwQdJ8ctHSaaopoqLfWvBSel7eZSupNwsvMBonQIk.b0sGgEGg0MESn7SLiMXgMFS.i81 cD1fh9v9HTTH5El6.W2ax4Phy2SZB.61ZN647hCmhiT236sCT6xn9e6jqkBkI8HIzhpjgJtriR9t XNFo- X-Sonic-MF: X-Sonic-ID: e1d4d38a-f20c-427c-83bc-02bd614c3a58 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 01:06:08 +0000 Received: by hermes--production-gq1-67d9c848cc-c9zv9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0162088fb9bd1a87ff3b7697755244e6; Wed, 19 Nov 2025 01:06:02 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #1] Date: Tue, 18 Nov 2025 17:05:51 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.73 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.73)[-0.728]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4dB3Fw6pZpz3DjN [I came up with an addition type of note to have for these tests.] On Nov 18, 2025, at 16:29, Mark Millard wrote: > I'm only sending notes from testing of how similar other failures = appear > to the 2 lists. Folks can ask that I do otherwise for them if they = want. >=20 > This one is for size 4096 (1 page). It looks like #0..#15 are similar = to > the original report but #16 is not. #15 is for: arena_malloc >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 > #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 > #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2a80d00= 0, size=3Dsize@entry=3D4096) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 > #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff7b87, commit=3D) > at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 > #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D4096, alignment=3D4096, zero=3Dtrue, commit=3D0xffff7be7,=20 > growing_retained=3D) at jemalloc_extent.c:1003 > #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 > expand_edata=3D0x0, size=3D4096, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 > #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D4096, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 > #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D4096, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 > deferred_work_generated=3D) at jemalloc_pac.c:178 > #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D4096,= alignment=3D2147483615, zero=3D, guarded=3Dfalse, = frequent_reuse=3Dtrue, deferred_work_generated=3D) > at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 > #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D4096, alignment=3D, slab=3Dtrue, szind=3D1, zero=3D, guarded=3Dfalse,=20= > deferred_work_generated=3D0xffff7caf) at jemalloc_pa.c:139 > #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D1, binshard=3D0, bin_info=3D0x2a21fa8c = <__je_bin_infos+48>) at jemalloc_arena.c:839 > #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e42e8, = cache_bin_info=3D0x2a6004c2, binind=3D1, nfill=3D100) at = jemalloc_arena.c:1034 > #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e42e8, binind=3D1,=20 > tcache_success=3D0xffff7d5f) at jemalloc_tcache.c:238 > #14 0x2a15e538 in tcache_alloc_small (tsd=3D0x2a2e4060, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D16, binind=3D1, = zero=3Dfalse, slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 > #15 arena_malloc (tsdn=3D, arena=3D, = size=3D, ind=3D, zero=3D, = tcache=3D, slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 > #16 iallocztm (tsdn=3Dtsdn@entry=3D0x2a2e4060, size=3D, = size@entry=3D16, ind=3Dind@entry=3D1, zero=3Dfalse, tcache=3D0x2a2e42c8, = is_internal=3Dfalse, arena=3D0x0, slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:55 > #17 0x2a164df4 in imalloc_no_sample (sopts=3D0xffff7dfc, = dopts=3D0xffff7ddc, tsd=3D0x2a2e4060, size=3D16, usize=3D16, = ind=3D) at jemalloc_jemalloc.c:2402 > #18 imalloc_body (sopts=3D0xffff7dfc, dopts=3D0xffff7ddc, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 > #19 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff7dfc, = dopts=3D, dopts@entry=3D0xffff7ddc) at = jemalloc_jemalloc.c:2693 > #20 0x2a156000 in __je_malloc_default (size=3D16) at = jemalloc_jemalloc.c:2726 > #21 0x29e61990 in operator_new_impl (size=3D16) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:34 > #22 operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:47 > #23 0x27e101d0 in __libcpp_operator_new () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/new:265 > #24 __libcpp_allocate () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/new:289 > #25 allocate () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__memory/allocator.h:118= > #26 __allocate_at_least > () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__memory/allocate_at_lea= st.h:41 > #27 __init () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/string:2336 > #28 basic_string () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/string:1078 > #29 str () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/StringRef.h:217 > #30 str () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Twine.cpp:29 > #31 0x294076d0 in SetNamePrefix () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:502 > #32 visit () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:2734 > #33 0x293f4938 in rewritePartition () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:4893 > #34 splitAlloca () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5284 > #35 0x293f04ec in runOnAlloca () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5485 > #36 0x293ebfc0 in runSROA () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5596 > #37 0x293eba80 in run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5637 > #38 0x27b9b32c in llvm::detail::PassModel>::run(llvm::Function&, = llvm::AnalysisManager&) () > at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 > #39 0x276eef80 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 > #40 0x2217fd38 in llvm::detail::PassModel>, = llvm::AnalysisManager>::run(llvm::Function&, = llvm::AnalysisManager&) () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 > #41 0x276f30e4 in run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/PassManager.cpp:124 > #42 0x22178b88 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () > at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 > #43 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 > #44 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 > #45 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 > --Type for more, q to quit, c to continue without paging-- > #46 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 > #47 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 > #48 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 > #49 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 > #50 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= > #51 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 > #52 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 > #53 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 > #54 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 > #55 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 > #56 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 > #57 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 > #58 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 > #59 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 > #60 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 > #61 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 > #62 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 > #63 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 > #64 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 >=20 > 0x2a80cfd0: 0x000013f2 0x00000079 0xffffffff 0xa5a5a5a5 > 0x2a80cfe0: 0xffffffff 0xa5a5a5a5 0xffffffff 0xa5a5a5a5 > 0x2a80cff0: 0x000014a6 0x00000079 0xffffffff 0xa5a5a5a5 > (gdb) x /1024x (size_t*)addr > 0x2a80d000: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2a80d010: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2a80d020: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > . . . > 0x2a80dfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2a80dfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2a80dff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > (gdb) x /1024x ((size_t*)addr)+1024 > 0x2a80e000: 0x00000051 0x00000002 0x29e862b8 0xa5a5a5a5 > 0x2a80e010: 0x7273752f 0x6372732f 0x766e692d 0x69747365 > 0x2a80e020: 0x69746167 0x6c2f6e6f 0x632f6269 0x676e616c > 0x2a80e030: 0x636e692f 0x6564756c 0x745f5f2f 0x5f657079 >=20 > So: All of the page was 0x5a5a5a5a repeated. Before and after > had some other values and were accessible. >=20 For #0..#15: The original example and the above agree about: #5 __je_extent_alloc_wrapper zero=3Dtrue #14 tcache_alloc_small zero=3Dfalse #15 __je_extent_alloc_wrapper zero=3Dfalse (The others are optimized out.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 01:14:46 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 4dB3SH1Sv2z6GxBN for ; Wed, 19 Nov 2025 01:15:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4dB3SG082Nz3JTp for ; Wed, 19 Nov 2025 01:15:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=V9i1vkRj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763514902; bh=Z2pSRaNauIxqiFIPZqOguiFbqdZXR5SOmEaCcCjk89Q=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=V9i1vkRjG029Vm8Mu1ILieT8oUspPurpm+Q0MvU7bjJXYrUczM+qUxBpDQsQOI+a4d744lcUH32Y5yfnD8MZhILavdBkJH4ph+0fweAeB5hj0n73o91mY2P8VgouYwV33U9HFQ3Ym3WSRQ0JHlgPJg2FscLb2MJEdsg3eyJhqBVK6NBn8za/2HbkKzE6GkJTRiJz6xeDPy/yCLNjZPpGjgEvXc5WOK0bGLjdw4UhM580Rka8x6pQ3oWTvGP+Oy6YRrZKnzKey8aRbeLOP3bAE1y/08HFdczUT4eRinLNsJcbZAkmWYeV4V+yjBGgmDEOrirAuDb84XBsFbxvjM1mRw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763514902; bh=SCD1ZFtoK9em6qBCGoYdvlYb38OgeJQzw9xjQEqALQv=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=UhUXiT/EdRB8VDtZ49DYTG7R3ZQt8VCKmzPBYOSkcRL4npZfl6phbZTDaraQVW4GTwW/0337drSkiBrFpY+kGHcF8AVrRvlKC2ZAWVmqRUEsGhl7AvKNha53E0BOyuzmjaWXNFCvI+6doYWokfqL/LxIK36fwV+JlRFX17vqN6Mit/5aEoZdFUT7xCnt19qXDCZtM4Elt2mo+Bcbtz4YhDFg8pqQbjyzhjaG3OXr9efXc5PJc6TBJBl97NKAb1NC41XWa3YCUmTzw2YPpAk2l42Z4nV6eYDHT8fCHqUfezi4Y+pslFdYJ4511yLm7zLOcb8M/v9TWcIXsgqvvmF1jA== X-YMail-OSG: jZ8A0TQVM1l5gdgZm.yTjhmUszBevfS9bOfKl8eEFe3Kcq3HYAKHl3H5AJb5Jnm HDGzeXlbCKX.h6nkdXbLQVTFLzxGG8dLGdFotT8kIT4.olfJlGiT6jFOjPuqKmodg1m0A3MHxYRn MydqqpLYEc0RCfww2n1ueAMYbHia1FeCDFu1NjoAOJy3mwqf0c6.1UpJcG20r0ZCbejxdeya4ZmX VSn8ZVaz5y_gNN6BY9Ebhfrybl6uQXsYaOOnjNBp_N9PjVieFlmWvBUY6vwbdcGkK0HGCVFn3i4g NxqcGk69Gv34cRubyb61.hZl88jUcKh.HLbZ.WPQO_DniSZswtTd3ID3okkT.9M1a.Prr5a4g35y sZicO2LIJbKCY9fovZVHjSLzOa16pG.zh42WhiGHG92Z6OgfDYWOcl8v7A5S17j.d97DnUOjb7Yl 9RaL8HVrf.8DWSOjST_LaDB.UUlUhpRDHXRlUS0rXwy13xxcUha4g98WHFbA9EHXXy9VSDHXQsTx bjaa6aN4hozzpGLFlg1dQUldstB3a3FlgayiK6UqdMwc7fR1dUNS6rKxBl.ijTDySmgYTTepT38X bdk3IJ4yhyGlfEfa5.N8lIuW.srY.vHhT7rMqOhvrTIXfTY_JJyF7tXo3vb.nDi7bEFpf36AR_um iYyOvF.elZJTYdyMeBi11IuMPiPvcUgLCafy..IRMWXSfNlA00j07XL6Jy2l6GsXJ_pVk1fIZ2EX 0lDyR37jggGVQVs2JJlhcvP3FVXDnWXO0nZb0luH3R_DBzTod5ZWtoleyfExprqd01NajTASWPaO KGaeHlbTE1M2T2ZN3ZbPMga.hOOvvrZYtUjKEBrjHW0NxCJSgex_KnYGLSO2aLzo0DoB_hKI3H2N q8aOs5y3awpj3DbBlGzRKxzg0E3hMf_GgkDpCGTdmQ4_hE10e82gxCZ9HsaijW1.j3lJwnZ7tdVu DQJjHhBkM848Myns91fgqO5fJlSeclVDsmjaJIoRujjrZKWTGvXHW7p6NEohRc5lhJmv6iZvRzi_ cdLNd360pu1b81NyUgLIYiBgvf4CFS.9M9a5Zzm7lTbW3kKujGVf0F4HcnBlCG4vjcuLJmmR9jpY hay2FUIXQ2yBBKwaFtt.ukDOqwidGZShERI3AiRCBGRtMwFkoFozGSiH_IfTJydIqndkQ4VxuJX0 aI3UYLr.NqQo4LC6KLxNSS3oDoYDHLTdNMmBj2bI5ejZ2PHepe491EjwrQqF7XQLHfsre8WNuR6Z B2h6c91Ck_yOj0dH.OvrJIpcecK52GzyI91XxwAaLI2lOpyBN7UTg7g4WGWJPud9QbbKCmSpzVcl gaIuu_c.4NwUsf9nlip6NlnNcwD9lln2yBpLliWpMsU6zoAwDebZtav.SMsO7HlJ3nosnJf5Rb3z ZnU3QyJG0j8aShJa55zYNshD9OUQD0wYeUZASsr55eaiiTKgPW.dFaHj9tDWR743ZlN9lMdxO4kf 2vrXUfvSC6qsH_O3wf4mujV73Jrqitelk3igN9Gr.yW8Bl02DiyKTvWfWTbYy66rEWw.M89pnl3D X7AT2knV_5GpR_WGv.KWLBNFqK9fdV1hqoZhHb5x7FTTy31ykFynr460jwnCK.IuRxLZ.ml09C3g _dUc35YnfYt93EN3zT5RH5JtzzoAUQa_LDYtucD2MjmdjVjFo2amq4gTw2p.lC8F5Kk6zFR4.ISH u3hVrgb8P7ubzAWuhwb_InLKwHAygGSCmag1YkqQLmRNhIDKq9NrbVYteU_N.lJ3UGJiTZCL96Ku J..ban3uGRAHxwTX0ke3b_25hV3QMbb9TzcczAM.eUP_zbcfwv2n9gCkHAd.uQNm5JKZb7RtP_lN OoN3OFqb6q7SXIFxGvpkog_8.xPXBNv25Ji6ctx7SWM_krv5rJWxrDWv6ywpHy.r22nBcQUEHhN0 RoBnGqUSpXa8FUwSp0tEyVtAHlo1NVIRuGWLVWIDWjShAb0fVkyXjt3QIu3QR98XWZUEVdWmvPGv 00RKworBUimeskpH98G8ln.8uo7WNEpADlosPJ1LsqO7_GPfBUIKpCmM85lw61B6pXTvH7UrsNnl jZ0.jBfX8tNY2s789KkDyQoPFDwpv7FYvVESQO0N.JXlM.90Yh360zJlNJp1jY7MIrh3bGlAGoSI G.Nf05vDJXUQeFDL57epalndEr8Nqvhm.yAEV5.SrHVrTzih6g0NcoKlMndEFJvXBqaWcOVSbdKo Y6gxL3SpMc41v_gCBPmvqFG4Tc8Dv5Eum4CT0vecPgKjtx2g_aYWTpPUrdbsvUpt3mRh50bDlhb6 XIA-- X-Sonic-MF: X-Sonic-ID: 160be1f7-5fde-41f4-b772-91c969e2166b Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 01:15:02 +0000 Received: by hermes--production-gq1-67d9c848cc-5thdf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 084a940ab62cb7bd4086cc1de23d3a77; Wed, 19 Nov 2025 01:14:57 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #1] Date: Tue, 18 Nov 2025 17:14:46 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: Message-Id: <2265C8CF-F12B-4EC5-91B5-D3B0289F440E@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.72 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.72)[-0.716]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4dB3SG082Nz3JTp [I misattributes a zero=3Dflase to #15.] On Nov 18, 2025, at 17:05, Mark Millard wrote: > [I came up with an addition type of note to have for these tests.] >=20 > On Nov 18, 2025, at 16:29, Mark Millard wrote: >=20 >> I'm only sending notes from testing of how similar other failures = appear >> to the 2 lists. Folks can ask that I do otherwise for them if they = want. >>=20 >> This one is for size 4096 (1 page). It looks like #0..#15 are similar = to >> the original report but #16 is not. #15 is for: arena_malloc >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 >> #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 >> #3 0x2a196128 in ehooks_debug_zero_check = (addr=3Daddr@entry=3D0x2a80d000, size=3Dsize@entry=3D4096) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 >> #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080,= new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff7b87, commit=3D) >> at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 >> #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D4096, alignment=3D4096, zero=3Dtrue, commit=3D0xffff7be7,=20 >> growing_retained=3D) at jemalloc_extent.c:1003 >> #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 >> expand_edata=3D0x0, size=3D4096, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 >> #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D4096, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 >> #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D4096, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 >> deferred_work_generated=3D) at jemalloc_pac.c:178 >> #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, = size=3D4096, alignment=3D2147483615, zero=3D, = guarded=3Dfalse, frequent_reuse=3Dtrue, = deferred_work_generated=3D) >> at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 >> #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D4096, alignment=3D, slab=3Dtrue, szind=3D1, zero=3D, guarded=3Dfalse,=20= >> deferred_work_generated=3D0xffff7caf) at jemalloc_pa.c:139 >> #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D1, binshard=3D0, bin_info=3D0x2a21fa8c = <__je_bin_infos+48>) at jemalloc_arena.c:839 >> #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e42e8, = cache_bin_info=3D0x2a6004c2, binind=3D1, nfill=3D100) at = jemalloc_arena.c:1034 >> #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e42e8, binind=3D1,=20 >> tcache_success=3D0xffff7d5f) at jemalloc_tcache.c:238 >> #14 0x2a15e538 in tcache_alloc_small (tsd=3D0x2a2e4060, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D16, binind=3D1, = zero=3Dfalse, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 >> #15 arena_malloc (tsdn=3D, arena=3D, = size=3D, ind=3D, zero=3D, = tcache=3D, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 >> #16 iallocztm (tsdn=3Dtsdn@entry=3D0x2a2e4060, size=3D, size@entry=3D16, ind=3Dind@entry=3D1, zero=3Dfalse, = tcache=3D0x2a2e42c8, is_internal=3Dfalse, arena=3D0x0, = slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:55 >> #17 0x2a164df4 in imalloc_no_sample (sopts=3D0xffff7dfc, = dopts=3D0xffff7ddc, tsd=3D0x2a2e4060, size=3D16, usize=3D16, = ind=3D) at jemalloc_jemalloc.c:2402 >> #18 imalloc_body (sopts=3D0xffff7dfc, dopts=3D0xffff7ddc, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 >> #19 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff7dfc, = dopts=3D, dopts@entry=3D0xffff7ddc) at = jemalloc_jemalloc.c:2693 >> #20 0x2a156000 in __je_malloc_default (size=3D16) at = jemalloc_jemalloc.c:2726 >> #21 0x29e61990 in operator_new_impl (size=3D16) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:34 >> #22 operator new (size=3D) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:47 >> #23 0x27e101d0 in __libcpp_operator_new () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/new:265 >> #24 __libcpp_allocate () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/new:289 >> #25 allocate () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__memory/allocator.h:118= >> #26 __allocate_at_least > () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__memory/allocate_at_lea= st.h:41 >> #27 __init () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/string:2336 >> #28 basic_string () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/string:1078 >> #29 str () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/StringRef.h:217 >> #30 str () at = /usr/src/contrib/llvm-project/llvm/lib/Support/Twine.cpp:29 >> #31 0x294076d0 in SetNamePrefix () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:502 >> #32 visit () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:2734 >> #33 0x293f4938 in rewritePartition () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:4893 >> #34 splitAlloca () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5284 >> #35 0x293f04ec in runOnAlloca () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5485 >> #36 0x293ebfc0 in runSROA () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5596 >> #37 0x293eba80 in run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/SROA.cpp:5637 >> #38 0x27b9b32c in llvm::detail::PassModel>::run(llvm::Function&, = llvm::AnalysisManager&) () >> at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 >> #39 0x276eef80 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 >> #40 0x2217fd38 in llvm::detail::PassModel>, = llvm::AnalysisManager>::run(llvm::Function&, = llvm::AnalysisManager&) () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 >> #41 0x276f30e4 in run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/PassManager.cpp:124 >> #42 0x22178b88 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () >> at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 >> #43 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 >> #44 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 >> #45 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 >> --Type for more, q to quit, c to continue without paging-- >> #46 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 >> #47 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 >> #48 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 >> #49 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 >> #50 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= >> #51 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 >> #52 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 >> #53 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 >> #54 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 >> #55 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 >> #56 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 >> #57 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 >> #58 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 >> #59 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 >> #60 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 >> #61 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 >> #62 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 >> #63 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 >> #64 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 >>=20 >> 0x2a80cfd0: 0x000013f2 0x00000079 0xffffffff 0xa5a5a5a5 >> 0x2a80cfe0: 0xffffffff 0xa5a5a5a5 0xffffffff 0xa5a5a5a5 >> 0x2a80cff0: 0x000014a6 0x00000079 0xffffffff 0xa5a5a5a5 >> (gdb) x /1024x (size_t*)addr >> 0x2a80d000: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2a80d010: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2a80d020: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> . . . >> 0x2a80dfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2a80dfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2a80dff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> (gdb) x /1024x ((size_t*)addr)+1024 >> 0x2a80e000: 0x00000051 0x00000002 0x29e862b8 0xa5a5a5a5 >> 0x2a80e010: 0x7273752f 0x6372732f 0x766e692d 0x69747365 >> 0x2a80e020: 0x69746167 0x6c2f6e6f 0x632f6269 0x676e616c >> 0x2a80e030: 0x636e692f 0x6564756c 0x745f5f2f 0x5f657079 >>=20 >> So: All of the page was 0x5a5a5a5a repeated. Before and after >> had some other values and were accessible. >>=20 >=20 > For #0..#15: The original example and the above > agree about: >=20 > #5 __je_extent_alloc_wrapper zero=3Dtrue > #14 tcache_alloc_small zero=3Dfalse > #15 __je_extent_alloc_wrapper zero=3Dfalse #15 was actually optimized out. It was #16 that was zero=3Dfalse. (But that is outside the common range #0..#15.) > (The others are optimized out.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 01:24:12 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 4dB3g45fZ0z6Gxyy for ; Wed, 19 Nov 2025 01:24:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4dB3g20tPtz3Lgj for ; Wed, 19 Nov 2025 01:24:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qZWL8GJ1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763515467; bh=SRkS6g13vnu226bLiHeLeyzHS/xPFgWsKQYFQfz2kUk=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=qZWL8GJ1O2v3oH+Hs0m3w5jXH8KY3fIrRlDfFhUNh4EOT7b0W9dHXi6iOTHWvGMlPWbz2It7wp8j4SapYqOIo33u+sKuNfBYTY8CVBqBzGuhVRqyQvkXbTGCIKhPpScYkUFVczqEwRU++HQlI4+kOaFIhm0qTVrI0zOz5A/QDfyX0uWOL9UJOmwnv3uT5YomdHdqMhP5Ajfoqnwt2cY7u1VihjyPE/GA8jt3+WH6X9pOPVujythpyJWyNhAV97RJjzZZg9N0gujtTfDGBIBBezSbgVarXZS1LpE2H5wgY3/aJKdM/IoNsoJrEhw1PwJ58x4NjKWbdUo9tS7hE3i7Cw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763515467; bh=Cg53wxtfmZ2xJOxzdAsZl0nDoUUaq0PHLUeeweumoPM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Pq7rDPWeIfTf8KII0mclAZenLdUAP3poEk8HE0JMEmbyzsfzmKlGOPW1gpOMjSM58bMQtPUCA/Di5zF7ZUDjrhHUqDhXcT+TOoN2J+fjDL3+ENtrTyzWUsbVuVEKifhwyj7jI04iUlOtCKM+mUmarEF0Wi+J7RRckMCQyhV/PsakR6p5OaVSC4TNXcw1uxSNs8SgeCWZyivpHfeG9mY+kZOJ4Pb8GPCYjVRpbLRZ5VAvMyMx+FCJGrxqlZ7/gSttp9/zxB7Ei/UNYmr8CdVuPh5N8XxFMVyfmqSEZdEUoxJQxA7+N72ickipoJbJI7sYrtCNe4DgoSbeQsy/0C/JvA== X-YMail-OSG: T1xd9ZgVM1ltlxAGyZViMZr3DtGtJ9bWtcm6FPHnDbL.dstrpqFDVmUCLiW.Tjs jttfM8k4Thkbeh8H4Xre8oKG.bNMez6xvZ0mn0YhdtUsIF8lXWZm2ByATresiMCowBN6_Aa1TbP7 ElsnB6Y_ggfwG0z5dqZehvt1Uy7g9IUKM2VYFki48HNHtkY2Ek3s175wkojkq1rq3p5KRei.XH60 oPtl5Jmm35GyvPsBIPC8FFaVdDlIwQhYZ5XrQmrJTnmQP1_C8r3OrodAZ03iajPm9rs4_iTJ9Q3e 12oBF2pj4GQNA1_GnaUyqVlmGJAdJ3zi.zdFwlMlKPI8Z_vg3D4lgBJE28VTZmHzscG4SDqWgb_9 3JLmwawGLNRVPAR10myz7Io2gFR9Pq0VMjspyrsH7G2jxAtAjLp2LDzhDTtRyj1zYc6FVjNCAAZD yjIEj1KBrmoNVJRuRJlG_IVQuAR1IyPJi6ptkrwFzjUQ0Zyur78mrrkC3LLhuiyAcnSViZHJALOR cz8ExamiJZ2WN1f9kwxr34nxLQ4pEzG_EyDwZG9lT6dhnPeen8S3_cGYrvjlYGz7MBp_1nnPMytk B6GEc_CigRIhl7Ua_fKYWXtEfmdUM83LJDepsATP7HV65S4ryO8cm3zHWsgpkxHIzO2HLDusIOz6 8_mW37x62S_GvqBxgLS6N.Qh00pjKBFkFQF9W7wrAEgnZWZEh484M9zBZSG5uP2aezJoXqBB4BXG qDB4DAKf4EoxHUjoxqRXdzseEs1dq5i7JDH601xkn5fuxBfC2XiixJ6_x7vkKU0BHIz3pKk1V2uY v_.d0js_mBaQNOn4FPzenU5.Nhj3wjlPGzm72VJgVin72PjI_VyoR1OEufjmN7SzOZsb4fbNtKBv TAc4j3Y1wsQSuAMC8IjILkk1M4l7.5iGdFteToY.QDyk7Ytc2KbbiEOoawwsbWGZpqUQ4lQHy8R7 udYEFeKbnhGoNV9NTDm0b8rbDghJ27osRqPRgOmnoGe7_dJYZoZFfNmWmo.L00hs70fmeI5YUiSh JLU.jBtSBjujH.ZbO3BsqwwZvbW0L.VbE5zRUrDieLRfpD9fmGAfaZNoFPVfGj6s_U4ipOx2gWCw Q4cuFTYTkE89r_QoVlAO5XP1z7P195gUjd12emnh5DlmWtDpvsVFchzISRe.NKyOTRxl0JNC3EkM ekCN6zvej_lzxa8Q891FqcOGmsGEjeJToCDNoxcSgwFa4AgCeMYSUMX5.ir9USOYzVLWotNCfqzC Nsw0_ZPd_p13KGJ3Yp7HF27hLl0UarhhhbJtdfZ91PlSG6u49rb68DU_1EVE6tewF3uQiDKlAqk2 UZeyawna4VWPIcWYg..abrJ7ETY_uxpsXYkI8F5JvMJmxmYxVclCnKYld4MohAkjEJbwA.CC7j1_ vR8kmNqLWILL7dCygf7vzM93VMd3YK4nwZkuAVNmxeaBCmTbu2ctD44LSO0bo_wLRACcHe.yKF.0 r9n30o7_l5kB84rsDbOxE0J0znaGftocYCuRa3.L_L3ZBubQUyCxBudhovC3RF7HW36tWHo4xIQ9 f_jOs5nIgmexAOUM7ON9LEom9Fv4NnKkyZVMRMmt.qrtNJpXYosFM01dCaClUcegeSz_4N7EhY63 lsGX..S7aomEnqqyaTh_ZYJZpxJBZ5TjukGtaczCfgxycSo9AUyCeD2uKXJYnfJ.CR9.QfSqpOqy nuNDjSBbG85Uif_I7S7Wd_OAYlJgATTgLsYWbeR2b6F9bu6AHthq8.ljCuuX_Hs69AVu8dMiFQPp rDiCO821ZOa6ulZr58_i8uV7Tr_QW6vlpdWaE_Z35zqFzTa.p0Hi26kZVILBF_vet1xyatmsTGcE ukj2V8Hqbxf3U7xGsqYNg1QeEB5e9r.SRn1Mg32eL4hf_wAFTZ1bJHoXw28FGC_k2kayZCRT9j3d 2XLc_eiW6NYhbtEpYs9nUtkNfqDWf3fPj8ND.b99Pmr5irKfAg7Qc07eAswoh7LokFc7INZZ.ncb rzeTtVJDlApT42HtIIAXhGvw2hi4SU.J24vK1KkHA.N5tpKh5FzRPwfCNz6e4bs0AgogqKvnNTo8 m83uEFwi3XmCAVaKKggE_8m1_hlKmgKXrgVgle0Q3MBoLu3JOJkUi_43uHbm38ElLu8qjDgk5gf7 qrXSGeNw7Yd3Y6NGUaXkbit65egvrkqvApLsytOzijyWu5mR01HBt77vYqQVA6_ataWMFwK.xDCI AKxG8v1ov4lFv.EOeg_O538bPn498Suk7Qjw0.2g1sKYHf1toqBXkAM0CJpikhmzoFJp6235dSTw 4YQ-- X-Sonic-MF: X-Sonic-ID: 9f63b868-e522-4477-a9e8-22a72223779a Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 01:24:27 +0000 Received: by hermes--production-gq1-67d9c848cc-qd2wc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b8e96cd66927ba56b21352f9bf0b5cb9; Wed, 19 Nov 2025 01:24:23 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #2] Date: Tue, 18 Nov 2025 17:24:12 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: Message-Id: <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.65 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_SHORT(0.35)[0.346]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4dB3g20tPtz3Lgj I'm only sending notes from testing of how similar other failures appear to the 2 lists. Folks can ask that I do otherwise for them if they want. This one is for size 4096 (1 page). It looks like #0..#15 are similar to the prior reports. #15 is for: arena_malloc (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2b9a0000,= size=3Dsize@entry=3D4096) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff79af, commit=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D4096, alignment=3D4096, zero=3Dtrue, commit=3D0xffff7a0f,=20 growing_retained=3D) at jemalloc_extent.c:1003 #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 expand_edata=3D0x0, size=3D4096, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D4096, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D4096, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 deferred_work_generated=3D) at jemalloc_pac.c:178 #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D4096, = alignment=3D2147483615, zero=3D, guarded=3Dfalse, = frequent_reuse=3Dtrue, deferred_work_generated=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D4096, alignment=3D, slab=3Dtrue, szind=3D19, zero=3D, guarded=3Dfalse,=20= deferred_work_generated=3D0xffff7ad7) at jemalloc_pa.c:139 #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D19, binshard=3D0, bin_info=3D0x2a21fdec = <__je_bin_infos+912>) at jemalloc_arena.c:839 #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4498, = cache_bin_info=3D0x2a6004e6, binind=3D19, nfill=3D10) at = jemalloc_arena.c:1034 #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4498, binind=3D19,=20 tcache_success=3D0xffff7b87) at jemalloc_tcache.c:238 #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D19, zero=3Dfalse, slow_path=3Dtrue) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 #15 arena_malloc (tsdn=3D, arena=3D, = size=3D512, ind=3D19, zero=3Dfalse, tcache=3D0x2a2e42c8, slow_path=3Dtrue)= at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, = arena=3D, usize=3D, usize@entry=3D512, = alignment=3Dalignment@entry=3D4, zero=3Dfalse, tcache=3D0x2a2e42c8) at jemalloc_arena.c:1224 #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, tsdn@entry=3D0x2a2e42c8, = usize=3D512, alignment=3D4, zero=3Dfalse, tcache=3D0x2a2e42c8, = is_internal=3Dfalse, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D512, = alignment=3D4, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff7c7c, = dopts=3D0xffff7c5c, tsd=3D0x2a2e4060, size=3D512, usize=3D512, = ind=3D) at jemalloc_jemalloc.c:2398 #20 imalloc_body (sopts=3D0xffff7c7c, dopts=3D0xffff7c5c, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff7c7c, = dopts=3D, dopts@entry=3D0xffff7c5c) at = jemalloc_jemalloc.c:2693 #22 0x2a15677c in __aligned_alloc (alignment=3D4, size=3D512) at = jemalloc_jemalloc.c:2821 #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D4, __size=3D) at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 #24 operator_new_aligned_impl (size=3D, alignment=3D4) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 #25 operator new (size=3D, alignment=3D) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 #26 0x223c87cc in allocateBuckets () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:915 #27 grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:849 #28 0x223c86fc in grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:580 #29 0x223c86fc in InsertIntoBucketImpl () from = /usr/lib/libprivateclang.so.19 #30 0x276ead50 in InsertIntoBucket () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:590 #31 try_emplace () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:247 #32 0x2957a02c in insert () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:228 #33 getOrCreateValueInfo () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Utils/PredicateInfo.cpp:= 737 #34 0x29579e28 in addInfoFor () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Utils/PredicateInfo.cpp:= 379 #35 0x2957a908 in processBranch () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Utils/PredicateInfo.cpp:= 462 #36 0x2957b3a4 in buildPredicateInfo () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Utils/PredicateInfo.cpp:= 511 #37 0x2957cc74 in PredicateInfo () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Utils/PredicateInfo.cpp:= 757 #38 0x29599084 in make_unique () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__memory/unique_ptr.h:63= 4 #39 addPredicateInfo () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Utils/SCCPSolver.cpp:692= #40 addPredicateInfo () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/Utils/SCCPSolver.cpp:204= 8 #41 0x28f4fc14 in runIPSCCP () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:130 #42 run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:403 #43 0x27b85d14 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 #44 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 --Type for more, q to quit, c to continue without paging-- #45 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 #46 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 #47 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 #48 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 #49 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 #50 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 #51 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= #52 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 #53 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 #54 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 #55 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #56 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #57 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 #58 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #59 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 #60 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #61 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 #62 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 #63 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 #64 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 #65 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 0x2b99fe90: 0x76202020 0x0a64696f 0x646e6523 = 0x200a6669 0x2b99fea0: 0x3e202020 0x3e203e20 0x2f2f0a3b = 0x616c6320 0x2b99feb0: 0x662d676e 0x616d726f 0x6e6f2074 = 0x4c5f0a0a --Type for more, q to quit, c to continue without paging-- 0x2b99fec0: 0x50434249 0x4e455f50 0x414e5f44 = 0x5053454d 0x2b99fed0: 0x5f454341 0x0a445453 0x6e65230a = 0x20666964 0x2b99fee0: 0x5f202f2f 0x4342494c 0x5f5f5050 = 0x5059545f 0x2b99fef0: 0x52545f45 0x53544941 0x4b414d5f = 0x32335f45 0x2b99ff00: 0x5f34365f 0x315f524f 0x425f3832 = 0x485f5449 0x2b99ff10: 0xa5a5000a 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b99ff20: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b99ff30: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b99ff40: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 . . . 0x2b99ffd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b99ffe0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2b99fff0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 (gdb) x /1024x ((size_t*)addr)+0 0x2b9a0000: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b9a0010: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b9a0020: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b9a0030: 0x00000000 0x00000000 0x00000000 = 0x00000000 . . . 0x2b9a0850: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b9a0860: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b9a0870: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2b9a0880: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b9a0890: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b9a08a0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a . . . 0x2b9a0fd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b9a0fe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2b9a0ff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb) x /1024x ((size_t*)addr)+1024 0x2b9a1000: Cannot access memory at address 0x2b9a1000 So: The page has a prefix of 0x00000000's and a suffix of 0x5a5a5a5a's, with no distinct middle. For #0..#15: The original example and the above agree about: #5 __je_extent_alloc_wrapper zero=3Dtrue #14 tcache_alloc_small zero=3Dfalse (The others are optimized out.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 01:57:21 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 4dB4PH5tQFz6H1m6 for ; Wed, 19 Nov 2025 01:57:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4dB4PH0Ksfz3PZ0 for ; Wed, 19 Nov 2025 01:57:38 +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=1763517455; bh=kW62n/VW9Qiq0G0XyhlhdD07eraroQKHV8uIsL6IZnA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IPHzHK/NJv0a8gtiSqHZKTDE+pbhhmRzsHLnTOgHSDL8XZ0Z2CPgBpwUZazWzdvow8vP4SmMibJnZaKp+4ICcJ/1ID0VLM7pC4MaZh4S6VCKRpnJVBFYoJuR7CpQTqjFhm0y2oH57sXNJahk5DvhqPeilc3pG5fTkr1qEwvAxx2ny29FY6Zr29WjXcQU7AAPpr8FXTc8bov1Rh1s90IT1bFX2PfZHmcP/1Ym3bXpv5o0oXbWAOlr3pA8v++QxFU15NOZefFrBIKvF74Q5Aowc5KdYw18dKsMFBF6uDQvD9frF/ymgch+FYllz/vNjd/sDYaTde+Te9crnUb3d+CXTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763517455; bh=0Le8ZQ4QTuQlLwcEAhD3cTVL9wWsXMPZ/Kz4/vy+u70=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HmPQ+8E6fCrS0cLC88gaRZ1kpRZv3kOEayZ3u7UWfdcHfOF1sM4dy5AXi6aqJWurRZtw6dziqDuhr3Wje9p1ZE3SRjLBZoX+yVLSaShC+yFp20pFDeeH+rfsH6nC6iXX6Opt3KlJMFPVz82/2wi1nmRo2+DP2C5jwFfscJJllQcNfTDe6nP2OK5V7hcNs/1bgGGy11si/WMk+l0LpnzEsLbYZ04IHo5ZFbfeJRPUY0IoX+HYeVdS3NURNoEcnTtdZBWyRfjBUwIYo3Kngnkh503kyFARjZzj25y5THuAFw9ElKIsY6xq9o4BTwf9dPBggKMSfwoWkTbKwz9++T3+7g== X-YMail-OSG: kvagNoYVM1nBQ4pC21hcFMWT_PX6rRtPXzksIS5nPk.M53GV_F03mYyXOmtLnpn cyL1s60gdyGu8MS6e8mSi6wm2Fv3Ro8nt81nQBpddvhN9qCmOMhUxavqDOGsfby4SKKRa0oOKots JMGTwSEvrYyqjuSzpqB7Vdzm3JbrvK8T2r3TSNSYsVkEbqAYq9Fhg.nADSQAlp2ewsZQ_fvsp.pp uNXF9sbs_hJGwm6NGxs1eWhVstauMSuYxBvT6oj_XFSmEGkf8yOETSsFBrnwAgQHtnHSlFhL3FPv bDrKwRwWQd1A490mKUJfJoilkgqIoYHxRXBZBY9iOz8x4iJkgZp.OrBvoq_VZG2RtOIb5nlCjfxG a2RrvG4dr_Gzu7aZy637RbIVodT_uFgKKfNIH5IfT1QIcsRPO5yzyUHZ3OxgJx7ruPtM.1V66lJj 5kR89b24Tll5QG3toviyG8KSp76AbcK.18jEFQljJ7Qiti2U6Mgt6HI9iGq2g0qwX_.vv5RREoeB 6oDmdxrrvG.Ct_SImHYVZQWLuDqLBOen9PfZSx0RPtB_fQChaloakXmg8xiXtoMtuihfeIe0J2qF ZkgFzxtPlrG8WkixHiZIirfNSaS5_6lqj2v4X._WnlPHYI42QvrY3pp1HpPaRtfJjofMt34O4dRh Pw6d20jIfm3NtBb_d3Qi9ebntWkhzbPxkkwlUwzzERW5cqaQ6OGyHqtLSSAfQwYEJ9PSNeTE2KhI JqYctjL9utgVzAiy9hSedGfmZZauBc9FOi0sGfPY4ZnN1BTa4H9f7EkRqhoLkNQwWKfEIOvTmIak 1xdStJTPVbNbrJLKcN3CaBXHXRBpxIiWvMNW.nWRUKuLWbIobDF6oCE3gacICOuczTJhApLc4Op. SRhRO47bB9d352L0B0KOeNE_qYKnw2n2DBfMp8TCPklH6pf06.b6t3vZbZSVpaadB30CeLS.LKlB s9dy7HYls6Gjr6RSaVmrEHmSHIp3JNcPopo_hmxWYS4AbfMsMFH3hP7G6XMcv96ihiKM3egguirB kIJiHRpODfui3Oeke_ETr4QhbTnZE7trOCRM8yDI9KvooTL9az2EPaM2GwqXewK6fOHSSEV_wM.K rCuf.2uY_KtYEF1LGe7I5apJroVoIj0043O0SBa2AYWsW2Oy3q2E.RczRldjcCDM0ySCM0jEo_Z1 q3HeThacVE8CeOCjpA1PLFmFsi7phV.cdhXqlt8L7Uvj60AQotR0ReLPjdSNk3ojYbMs29RMIjPl GWOWpP913bheT5HA_HmRPlC_v6n.7Weh8MlLG1bKw9oQ7oONh671azJdnXQIBLwCVicWv9j.VqNV mfY_hh.vNiJmKYUheLx491DABvXyMy86a4Hy.h85V0eNxjbcLSQABq8aBm_ZRgbXhKO3.bzyWLLo npcXQ5kquSxlp5BrVUGlo28dPScMJ1mAscPmPkTZ5X06qFu2vt.6PZwbJE61kSJvGqJmgPwt6egw q0hHDcXhD691hLp0JVvNK0W5BcBffS6D2g1fe3f6Di.aQB0y79m_NAz5sbUmasdYGBAxQs6WdwuY 6btPseFJLOGR5VRqYjog1eq3OrR6BYnhkD0pkl_uQOvCt.gXme5BXiUFEQ9BEZb7cXG2GCR1Hc6o l4qGuZc.5m4zazBzKfYi56qQK9jmeXwciTXwSc3cG89fcRIsKlq5kR.yFrW6dY.nxWJCkGL6WpmQ EZmPr.3JVQBamypQ0KlxalAlesBt2_FlhOpnA99of3Fo.RxRGdoQ0vtJcFXoMmW0AV3tWIjKHkgF uh4MAIoq.Buk9KxqMAzfueTQz5xdiAyTBD0ThEEkXGUQ.JyXip_XIusFTikKQjGMc9ARaW5GLgeO 6FQAgQpY52dj_JqNo2vjGy1CDjjK1PPKq97ejC6sIzhf6NnS2Tr3EKwSeaT8QzUy65vTV.OvNe6V aCP2PaX2nbrj1OknmP2..MtWx1cGIXcZNz8RQdd8JBAmK2glcXq23uES.ecAlFdwdSjpiIBwBUid 6u4trEOHMnOeKlMBp6QxiOrrkU_jyPbWw7aaU5mbKg14vG_vmcVajbId.EV0j9w.lkLmUi7yG_9o JwTacgXd3a4ObRfj1Rs0n51JJPumnwngbv0qP85z174Nxdtf_WwsGpOMsR5m_swFl_Rq5wjKbfJW QamPB4Uy3yeJOV4hdSaGJrx9s.r_NcIqRFnR5.unRFujDME9FrML1rRx9A6Gt5SEKeBJMKH8h0p6 c_Yv5G4fTp01wgy_bCZe3nel3sPnvR_W5QpbpM0dKHo3U5mJpbXfmab0o1ZgDOMJ0akj2S5y0UWl y6Q-- X-Sonic-MF: X-Sonic-ID: 2e194494-c560-4063-aef5-11f8ef0d2b69 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 01:57:35 +0000 Received: by hermes--production-gq1-67d9c848cc-5kcbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 668bb6d60385d26e935eeaff48f0b174; Wed, 19 Nov 2025 01:57:32 +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 [Notes from another example core dump: #3] From: Mark Millard In-Reply-To: <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> Date: Tue, 18 Nov 2025 17:57:21 -0800 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> To: "marklmi-yh.com" X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dB4PH0Ksfz3PZ0 I'm only sending notes from testing of how similar other failures appear to the 2 lists. Folks can ask that I do otherwise for them if they want. This one is for size 4096 (1 page). It looks like #0..#15 are similar to the prior reports. #15 is for: arena_malloc (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2e0eb000,= size=3Dsize@entry=3D4096) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff7e87, commit=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D4096, alignment=3D4096, zero=3Dtrue, commit=3D0xffff7ee7,=20 growing_retained=3D) at jemalloc_extent.c:1003 #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 expand_edata=3D0x0, size=3D4096, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D4096, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D4096, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 deferred_work_generated=3D) at jemalloc_pac.c:178 #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D4096, = alignment=3D2147483615, zero=3D, guarded=3Dfalse, = frequent_reuse=3Dtrue, deferred_work_generated=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D4096, alignment=3D, slab=3Dtrue, szind=3D19, zero=3D, guarded=3Dfalse,=20= deferred_work_generated=3D0xffff7faf) at jemalloc_pa.c:139 #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D19, binshard=3D0, bin_info=3D0x2a21fdec = <__je_bin_infos+912>) at jemalloc_arena.c:839 #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4498, = cache_bin_info=3D0x2a6004e6, binind=3D19, nfill=3D10) at = jemalloc_arena.c:1034 #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4498, binind=3D19,=20 tcache_success=3D0xffff805f) at jemalloc_tcache.c:238 #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D19, zero=3Dfalse, slow_path=3Dtrue) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 #15 arena_malloc (tsdn=3D, arena=3D, = size=3D512, ind=3D19, zero=3Dfalse, tcache=3D0x2a2e42c8, slow_path=3Dtrue)= at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, = arena=3D, usize=3D, usize@entry=3D512, = alignment=3Dalignment@entry=3D4, zero=3Dfalse, tcache=3D0x2a2e42c8) at jemalloc_arena.c:1224 #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, tsdn@entry=3D0x2a2e42c8, = usize=3D512, alignment=3D4, zero=3Dfalse, tcache=3D0x2a2e42c8, = is_internal=3Dfalse, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D512, = alignment=3D4, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff8154, = dopts=3D0xffff8134, tsd=3D0x2a2e4060, size=3D512, usize=3D512, = ind=3D) at jemalloc_jemalloc.c:2398 #20 imalloc_body (sopts=3D0xffff8154, dopts=3D0xffff8134, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff8154, = dopts=3D, dopts@entry=3D0xffff8134) at = jemalloc_jemalloc.c:2693 #22 0x2a15677c in __aligned_alloc (alignment=3D4, size=3D512) at = jemalloc_jemalloc.c:2821 #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D4, __size=3D) at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 #24 operator_new_aligned_impl (size=3D, alignment=3D4) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 #25 operator new (size=3D, alignment=3D) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 #26 0x276265a0 in allocateBuckets () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:915 #27 grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:849 #28 0x276264d0 in grow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:580 #29 0x276264d0 in InsertIntoBucketImpl () from = /usr/lib/libprivatellvm.so.19 #30 0x276262d0 in InsertIntoBucket () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:590 #31 FindAndConstruct () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:369 #32 0x2761e67c in operator[] () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:373 #33 createNode () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:8= 40 #34 CalculateFromScratch () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/GenericDomTreeCons= truction.h:579 #35 0x2762537c in Calculate > () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/GenericDomTreeCons= truction.h:1544 #36 recalculate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/GenericDomTree.h:7= 95 #37 run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/Dominators.cpp:374 #38 0x2644e598 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:3= 20 #39 0x276f1cf4 in getResultImpl () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:156 #40 0x262b8950 in getResult () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManager.h:409 #41 0x28f4fbe0 in operator() () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__functional/function.h:= 430 #42 operator() () at = /usr/obj/usr/src/arm.armv7/tmp/usr/include/c++/v1/__functional/function.h:= 989 #43 runIPSCCP () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:128 #44 run () at = /usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/SCCP.cpp:403 #45 0x27b85d14 in llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) () --Type for more, q to quit, c to continue without paging-- at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:9= 0 #46 0x276ee244 in run () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:81 #47 0x22174ffc in RunOptimizationPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1114 #48 0x2216cfb8 in EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1179 #49 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 #50 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 #51 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 #52 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 #53 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= #54 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 #55 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 #56 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 #57 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #58 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #59 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 #60 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #61 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 #62 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #63 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 #64 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 #65 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 #66 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 #67 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 0x2e0ebe80: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e0ebe90: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e0ebea0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb) x /1024x ((size_t*)addr)+0 0x2e0eb000: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e0eb010: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e0eb020: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a . . . 0x2e0ebfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e0ebfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e0ebff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb) x /1024x ((size_t*)addr)+1024 0x2e0ec000: Cannot access memory at address 0x2e0ec000 For #0..#15: The prior examples and the above agree about: #5 __je_extent_alloc_wrapper zero=3Dtrue #14 tcache_alloc_small zero=3Dfalse (The others are optimized out.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 03:03:16 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 4dB5sR4C00z6H70r for ; Wed, 19 Nov 2025 03:03:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4dB5sN45Xxz3Ypn for ; Wed, 19 Nov 2025 03:03:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OwgCAnZ1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763521412; bh=pBUyh6WpH3axkmiYcygM6uO4lUpuzKaBjvA+35U+Oy4=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=OwgCAnZ16aFvFUYBPpvtwH/2pijtHkytzBxIpJUd+o+dPoWCLeAryzEWxck/fMAYQSyCidyxMPCpzFYCzgBXmlK4UdOeSwrHKMtOrBR7VzM512LIFOIbFOLn4FjZ2RnkBpQnr8CTGKTAic+hgDPEeCKPBQLLHXJzmGnSCwL+DNWY8ztsaZcNCr55LtxnwFBGIi602tawb4tdHB3Xz/BJ7fcAEQO7enZVafpzoN75AjxevpQh5pMHhGYVHWND2nFMINR6NqSHTx66GW2SFIC5hia6txfF+BuRAHWklBlI2mvTJ1N1sbhQwSW5ubb1+iycUAZTg7+bRyfHnmUqJUdFEQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763521412; bh=e9qmK2HkGsg4N8FhzhiCGc8aNkk67VQAw7dV6hW65MA=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=AckGGeqLZgYV5+mgjUaiDhT9p3zA2HMrVtIyOKFlXeVM2bmSdO7fGz0P937IiSgavYv1ilSWhxZilfdGdbylPdX5D9HNY5rDoM2py8S/IXoywX3hUDuQXw1VsoQ4wGNQV4J2/7+or9BbaxpqdiGURrXXGmu4mt71E++7PZhMP96ieohJnjj7Kn6/gXpxzK9nQicKOpX9c7hMmUlcVAEZqVHrh2cj6x8PhZgELYP+8oXpOf/REgjLE2IS7RkpxzkmusWCgthh4INfb3KMovBPixDQjw0FB3zT/nj9C/lnXW3WumaOvuPp1Q5JRt9kVRK8rC6WXtf7/gI0xoAok6D3Jg== X-YMail-OSG: RtfTh6UVM1m.R5BF9gzZS9pYMdW7IG8fCyTo7tcJu6iLpVv1FMewODaiJQLAu.n by8xOBjDhC3LkQE3CK2uzO6IVxDhCNn1WgWvKzB67C91LPb7MmIA8Qg3vQ0bmkjH6YXt7d76ZycD XHB5HJDQaGoi6DYrXtsqNAmYgq1m6oOqwqY5.7JeEyGuIz7kp7S0EjfeuPy_DrF6bQDbqyOv3._7 yb9c6qpz6dYj_bl3PMSZG_42ct5Ap0zNUl8oz649ipAovH_BA9yqzRvMfDLeNTTF7ZB2rD8u0hi8 3T6f2qhsT596.DbFGTlDWYAZegNIA6CPmkdDuOlokjmE.GiYaR9gYu7m2eUNskrO5Y27rv1NfHeq dINVeFpGSOFNbbiM7skc3k48WYIHQKcRBkQUcNA.NNAxxIwYUmRTLdh9fPxc.Mb31H62Cv8gsV5L 5RGqvKeEbd9QorVRYP2XZewu_VS.YaDyPnfv3m30QvuQXDmaG7adNQ.otSeSZlCYMCvZXCsHwQfH pYpiJW7tNPdGH__4UM2PVz8YdexR9fPqIjrBHPq4BA7miv_xFhUT5sWglQ.Is2Teq0XEUiINoO56 hHfKb0fRYYimbk716BNBSYeVPi4yaQB6rk1_GPI8GAADWVC1Fgw4WcRHWrNOyCAb424iNQDNTcqK VVulqsvvesPUd31exbepuVqfmK986QMEqsBqnvGCi3K1IEoeRr0g9YTolr1kaf.eXsLd6PU5wCso 3ypFQvCM8MQDF_pu_XnEdTRV3J9c37Gh3FytBlQV.B_ey5k2_R58IhB6vLEK7Gw_6jn7gNg1T_N8 ODpPXjbmIGQtBzUBZKKv1fPtXT9G8ZOjEqwTQ2vH0kTUer0oqoNPQFWJ_Jkq1FSqoE98WkBtKCU4 KTdUHR0sYzMkUlw6MKuYv3Alo.08ikC.EWct9_VVbqxwbGXdzleSUMxYInP3JtboCvQ5nC5lp.OO TIgO71Q4GebAurKxwRzy_2ivUW1sr7z3I0FvCq.fqZSzdolbGV5REPDhpxSRX13JKk9IofcKxWwT hUpKoA_tFh3wYSnlraAxVAZEFgBnStWueobwEW..CxPDaCs1khAi4WBfKEQzu33fBLF25mhdp1ct iNcSAMgYXmzBOelZGnHa1_wgiYgKHsVWBj_dmf4zBEynbHiU8iDzfe_OcdZibM0pBKB5rFXZckyv YkUClcHLW1kDwQl7t44bVqW_OdscCFXIw.0.Ij7DrY72PRRNqoi79WOhmahZd3RocbNBz.DrlekM mpdxGs4.79ni1SlRa7A9j2rpC7M0MS3UGXeCTC2Vd7NBqnVdWABiEkcSzpifmIj7eNyoqkyYub3I Tlf2hbIOlJODSIExJ8eO9d2ahZgwzpRMkKr3YA8JgkfK_9jZ1xwdL2WRl4r.fX_eISSHt1cNBD.0 iA.a.7Ri6MHju3RQnsFF.5L.2wtCQHeDNDcHxuTBypmNvnSzlfnXB8GnKpJ43qxK.2mqsvLorGDL frwkz8iiSHl5Hi8qV6M3LZqAK.F2bTsO0yiK_fFwc3dq3bOPL_dfR76C5fsUIy8za61Z6DAOKoBy iTbfhIFO1uVeear1Kg0C3FyhM5Z5juIzdl_3nT8iTb40Ah_QfcEYrkspbkDNHWyw4se3_8vHAsry 3qx3gRrIXxihZqB0LdoIx3TaumFyWcnaiRGxZIiwCbQiwFpnrzUgEpL4nLV5yzT2UCfe2UFtAN9u 4vwvkn1pqbbjVU26bJo9.6_KFSs1RzbEuhWa5WTftIBlEPbkhM.R0seUlcB4B2iYp3mRlAvffS9W YRBQFz8wO.eGoKrDxZIr5MEC_4A4G6QiFnp0j89.PGtwcbr3527roJFKKppdQFGurRL9.GCM50EZ Oh6GOpvEbPMSfiKEzCYkjIlYqVcppVILc1E6jYwioV.nrxDhgXCX5NeWknPHzgU82PBtVkqtbljG x2fnvIqr8fH72T7YUJb2P2AqFWNBfdqHMHfkhNmpdJ2x2.ruJobTJzPWbHAATOtQt_rzR17w8KFg EhBxtlQ0KLId9hDzfyOt2a2S_pJ_KiUec4dAgyB.501e_LkRlGwg0pLHiKZb_rw3E0mtAhkcVrpm AGaSkGLxkre5IaaqjAGQZuPEWHE3wOv.YWWDnFJh2woRZXCFol1FI9xg7nhsPO2ZbpSZkrNqWhRn YGsnTmK6n1DzvPWBZLJkJf9D2SC72vsjSkK8Vc94cjEDGNwGIXs0diqFv9tJc3bFPb8G5LTm_5e3 iX27EU1pmNS_rdzgzX.hRLlofEIK3 X-Sonic-MF: X-Sonic-ID: ce00c4f8-3f3e-47a3-af7a-6b9f5e39fbba Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 03:03:32 +0000 Received: by hermes--production-gq1-67d9c848cc-m5gpb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 31f51d6647e4aa6b8fe0a92a02be23dd; Wed, 19 Nov 2025 03:03:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #4] [New common range #0..#10 __je_pa_alloc] Date: Tue, 18 Nov 2025 19:03:16 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: Message-Id: <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.38)[-0.381]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from] X-Rspamd-Queue-Id: 4dB5sN45Xxz3Ypn I'm only sending notes from testing of how similar other failures appear to the 2 lists. Folks can ask that I do otherwise for them if they want. This one does not have area_malloc involved at all. This one is for size 20480 (5 pages). It looks like #0..#10 are similar = to the prior reports. #10 is __je_pa_alloc. #11 is: __je_arena_extent_alloc_large (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x34b1e000,= size=3Dsize@entry=3D20480) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff9067, commit=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D20480, alignment=3D64, zero=3Dtrue, commit=3D0xffff90c7,=20 growing_retained=3D) at jemalloc_extent.c:1003 #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 expand_edata=3D0x0, size=3D20480, alignment=3D64, zero=3D, guarded=3D) at jemalloc_extent.c:126 #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D20480, alignment=3D64, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D20480, alignment=3D64, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 deferred_work_generated=3D) at jemalloc_pac.c:178 #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D20480, = alignment=3D2147483615, alignment@entry=3D20480, zero=3D, = guarded=3Dfalse, frequent_reuse=3Dfalse,=20 deferred_work_generated=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3Dsize@entry=3D20480, = alignment=3D, alignment@entry=3D64, slab=3Dfalse, = szind=3D39, zero=3D,=20 guarded=3Dfalse, deferred_work_generated=3D0xffff9193) at = jemalloc_pa.c:139 #11 0x2a169108 in __je_arena_extent_alloc_large = (tsdn=3Dtsdn@entry=3D0x2a2e4060, arena=3Darena@entry=3D0x2a600540, = usize=3Dusize@entry=3D16384, alignment=3Dalignment@entry=3D64, = zero=3D) at jemalloc_arena.c:338 #12 0x2a1976fc in __je_large_palloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D, arena@entry=3D0x0, usize=3Dusize@entry=3D16384, = alignment=3D64, zero=3D) at jemalloc_large.c:37 #13 0x2a197230 in __je_large_malloc (tsdn=3D0x2a2e4060, arena=3D0x0, = usize=3D16384, zero=3Dfalse) at jemalloc_large.c:17 #14 0x2a16cb70 in __je_arena_palloc (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, = arena=3D0x0, usize=3D0, usize@entry=3D16384, = alignment=3Dalignment@entry=3D8, zero=3D, tcache=3D0x0) = at jemalloc_arena.c:1228 #15 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, tsdn@entry=3D0x2a2e42c8, = usize=3D16384, alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, = is_internal=3Dfalse, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 #16 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D16384, = alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 #17 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff92a4, = dopts=3D0xffff9284, tsd=3D0x2a2e4060, size=3D16384, usize=3D16384, = ind=3D) at jemalloc_jemalloc.c:2398 #18 imalloc_body (sopts=3D0xffff92a4, dopts=3D0xffff9284, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 #19 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff92a4, = dopts=3D, dopts@entry=3D0xffff9284) at = jemalloc_jemalloc.c:2693 #20 0x2a15677c in __aligned_alloc (alignment=3D8, size=3D16384) at = jemalloc_jemalloc.c:2821 #21 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D8, __size=3D) at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 #22 operator_new_aligned_impl (size=3D, alignment=3D8) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 #23 operator new (size=3D, alignment=3D) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 #24 0x20ff35f8 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:92= #25 StartNewSlab () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:344 #26 AllocateSlow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:200 #27 0x267d7424 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:176 #28 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:214 #29 operator new () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:448 #30 addValue () at = /usr/src/contrib/llvm-project/llvm/include/llvm/CodeGen/DIE.h:741 #31 0x2680e144 in addAttribute () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.h:95 #32 addUInt () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:22= 7 #33 0x267ce318 in constructInlinedScopeDIE () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit= .cpp:721 #34 0x267ce010 in constructScopeDIE () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit= .cpp:601 #35 0x267cf328 in createAndAddScopeChildren () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit= .cpp:1161 #36 0x267ce094 in constructScopeDIE () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit= .cpp:615 #37 0x267cf328 in createAndAddScopeChildren () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit= .cpp:1161 #38 0x267d1790 in constructSubprogramScopeDIE () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit= .cpp:1101 #39 0x267e7320 in endFunctionImpl () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2= 337 #40 0x267c92ac in endFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/DebugHandlerBase= .cpp:419 #41 0x26778bcc in emitFunctionBody () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1= 987 #42 0x2825f94c in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/Target/ARM/ARMAsmPrinter.cpp:168 #43 0x26c15e88 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:94 #44 0x276a9e74 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1440 #45 0x276b0d40 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1486 #46 0x276aa5e0 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1555 #47 run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:541 #48 0x2216d2e8 in RunCodegenPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1157 --Type for more, q to quit, c to continue without paging-- #49 EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1180 #50 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 #51 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 #52 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 #53 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 #54 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= #55 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 #56 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 #57 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 #58 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #59 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #60 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 #61 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #62 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 #63 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #64 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 #65 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 #66 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 #67 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 #68 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 0x34b1dfd0: 0x34b1dfdc 0x00000001 0x00000004 = 0x2a436f28 0x34b1dfe0: 0x00000000 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x34b1dff0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 (gdb) x /1024x ((size_t*)addr)+0 0x34b1e000: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x34b1e010: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x34b1e020: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a . . . 0x34b22fd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x34b22fe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x34b22ff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb) x /1024x ((size_t*)addr)+5192 0x34b23120: Cannot access memory at address 0x34b23120 For #0..#10: The prior examples and the above agree about: #5 __je_extent_alloc_wrapper zero=3Dtrue But also there was in this example: #13 __je_large_malloc zero=3Dfalse (The others before #13 are optimized out.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 06:10:19 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 4dBB1C5y27z6H7tJ for ; Wed, 19 Nov 2025 06:10:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4dBB1B6qbHz3rQ6 for ; Wed, 19 Nov 2025 06:10:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VKIoZQhG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763532631; bh=Tm7jI37hu2wAGSuVs6jasYyPSL0pCcte7OFLd7AWHaE=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=VKIoZQhGRGVn7NWrkg0YvaGwlv2ai/ANjduU6Qce1g9wJlRoHISMwNZsM2Pf1rZBTWA1biMY+WGfFicjJzjwqtJkaGnOUYxNSkMvvpqOdzGsadElgnqTzik2JbjNvqygDf3aSizNgE1+YYmE2l0lzX2Q1EW/tgxA2jZaX+bFVZbP7BMtci7woflDwc5lClX4Eh6E4mQQuvyKben3uVe2aCCybdQs4Pw27JvXPwTD21jJc9om1yevgbTjX8iVFj28kYIvy9uWJ+uiDXNuMA4M3AnRP85z66i3hq1VRiAKTC5WdvuhUpRkSA3FW++kxIw0/Q7Lqs2iKigJQF1rwHMeRg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763532631; bh=ZviSPViU+c5be5eJma8brEjBbihYO89OibZIMy9q/QZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=A18HiUkbUa9zEO/aIs+dg75s6oHoH5A8w0IC9B2WeVhDmbkuhn4H1FFOKp6dZ4Y9s/OipuCoqGYWILb90OwNEVD5DNBHqyfQ5eeyYIOEKtYfvRxBMRSAuPEyeRg6w62HZHvOUpA4U0YGgp7lPKQz2NmEVfyNgXSAgZLGD7HMQmkZ8VaKUa20u6UG9QUE/AaxuQRos5g/jdux6prxPKepMGLfoFQK/tBx3uLvRHn8xmEeC/VM7nH8i4THPXGLUcqwI1OAm70zj3ryDQd+EFnwNAcR2VQFUA2WMEzKr1JwhXpNKgvdaN2wrCL7ynMcR7ONMnZGgfjNuh7VM+WGcJlpYg== X-YMail-OSG: ycoTqJgVM1k7f9aMhoBGWnSYW0b_pZX__3B8v9qX80lZGLMM83esf9UzN2H9QsX xfLd.ToJQI.Dvl61bRBwYs.ploCiI4Zq5LYB7ZMxxS6lUyVcNmb6yXFeZVOJYuwkpvQtu3PvNlYO rhDonfHz0PHBM9SvHLRHN4L_Y6maEVJQ2cLTUS34idvBy9CYxsfjX3Sv.bwLoB3F6Mz8or7KLGaE nrZ2X0dhYlh28t27FT.jiE.fuds5H7YCQgGlYXv9OZDQDQzpbX8jDhLu_2V3cDTZsl9tgbfl7BUF knlKVIVm.huqlFJ4wySNV7v3W_0TkUFL5wpP5UlkswLk5tF39z19yPG1R5i1AjINd6ygD_3wKJcB CxpYgupdDJUPOQFuHM91RpzHj27VjLZy4tts8B0YCWPSq3lt_gKpm66fw0EKVty1w7gcKgLKtAYb qHMz8HW92M5rQujrJ_1KZ6YMb_xgYVpioIrFvyY9PC6BswWWGd1zX5DNXfky_EeqhQ4iihKMfqyD EKERaxiWiUBObFP4DoHpjHuIP4Bxr8gd8oqe.HbJdTKmFJv2K0YRWlN_CfW0XzoQOzMgBQ31_eH9 7PNCDUjnyC2IH1Qr720M0pxZU1YyZJYkmkJBsmmT3sbhV1N0oMbwOu4tWy027_r8nUK9xfudJMTg iT87mmKK.vS3QaBUXIzHhtnV0Qb.XUnPg0BV0waXznVy9J_9je14QJYEeI6cE0_.qDXKKDQJocfy qU3G9v4p29ODpayaU46U6Iqk93WkzRnjnGmsspJmW.Y1uBCTgk0gJWi9MP32yOAhfUEUUvjv63.t BhAvNqa1l8gO1wVkP7RxVLMxtbOTiOxGg_XYCss5zVS62LEGC7clXfXDAqMEjKNFXvljaA_DPuHq S1KdGi89.Z2B__5XfwLAxe74AlGTYBzm2HOOFolU02rilpFzA3QNmz5OR_JfpDiUIQR8VOsI46GO N6lyAUQivGxp6P3djzuAgRIkmlqkx86X2BtK4C4hycFjc5OC.ajU3sZKocjO73j7B2.UWvalhXLN yM1RHxGnxDcU3GgZDyoTL6aqpgLJdqUDL5Uuar8JaBNp1wYnjiUmJX.3GYxok1l924YQxYSuxDbw GBRDWMiN8UmD5wbE55n0HbsjbKlK.9ihvhLkj2RPQqRexLHjlLyhymuILmU5f9CgSRIyyLoHzHwt oPNSiMWi2tTwzUN8HCC_BePQGQrgiEPTDrfjPAO0v7BjD_OuFraNmeBVIUCQZYEnc3c_RVuM.1R4 uPUffaSw3F3DWp_bFhEKG5DuY2HjLJIExRaOxKNGG6hI.dHyKOlU4ETF3lIeMhEpKclzhC8Ec9EX EEwTen5veNe0Ya9qqyrHn3AEnb.CVHx4.q9cwyDNia39Cz4ODW2iXst1aU_6dQOXkC1QQeL6_mS1 kZCn_cbcnNbpzvJQVLT7yDm6J3UbbRxtietCJ9D3SLqSU9bY6dI8kx2alxAaKW2bSPMKlxFVGcYJ 8z2IlA4Us5BLRXDQBI2KkANS3tXbIK39qOumtuT7JurIQQ2dMKlBzztoFZwHmeA7Cql2xygUT8mo n78o3_90mV_l9wMf8Rp7Szbke8ukEVlbFMrixNs1IN8ch1734cs1X554oXUzpqYuT9UEbdT59kTf 8NbCowthQY3j1YS7jpLVOdc1YAT_1bAsjvGrqsydwmZ4R0Mvnw3wZngkaWdGUV9Ggk5dgS5Gi.xp hV8LvdhsaEq.wNo4Qmdny.r1g1PPOCWX4K.tfUu6PtO1M85GM8DoPWoE1XQoPBeq9FDNrCytDAJC KhNkDzVU5VosZ0FwFoL9RkGqhYG5T7jtN3gRigfwCHg6XsfmHJuY6TWgLuSTQXSiueJP1W8xxz5H CHwAYa8GVmAmKr8tpaTMuL8DlkCsa9xrNtH7RZc1WjuHZrggaBAJoquMAfC2489hYtD05VNvlM6L g1eQ0kL9yjI8Qa3iG7oqwoMAE.Hsxyo4iE3lbZ98b4OjZqfyKqMGyXw95kGwoTcsPyKOsY8rknrZ h3Sm0o7yzkeR0XSuMmWM2AZ84xGA_Vqp02EkpOSdyPRsbZy_jadC.IyMqy8GdGfqUFEDV4754RQ. 22gszkIalVNd_pkE8zzALpgbqVPLjK80dsX5KZLzfz5jGESHK_riNn36rTGUk5Nx70tag0s4BrW5 ya5JWKPb2FfWdpPBOYnsFZ7L9VFs1rytO1.NW0ejRAY2CM6Ae7.n8JCBbWbVZ2u2jRiekYeYL0aN QnaYlqtfFjyREyo10ksajN3VyAa7EVHB0ZtOMKBooHFN2Tr4u1xNaGkLfady6JbZua4bon8oayph 1IVs- X-Sonic-MF: X-Sonic-ID: 31d317ec-ffcf-4b45-984e-84e5d6967134 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 06:10:31 +0000 Received: by hermes--production-gq1-67d9c848cc-h6lbx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 560cd10cfc7c8f25194806c1cdda0328; Wed, 19 Nov 2025 06:10:29 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #5] [Common range #0..#10 __je_pa_alloc] Date: Tue, 18 Nov 2025 22:10:19 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> Message-Id: <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.68 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.68)[-0.684]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from] X-Rspamd-Queue-Id: 4dBB1B6qbHz3rQ6 I'm only sending notes from testing of how similar other failures appear to the 2 lists. Folks can ask that I do otherwise for them if they want. This one also does not have area_malloc involved at all. This one is for size 8192 (2 pages). It looks like #0..#10 are similar = to the prior reports. #10 is __je_pa_alloc. #11 is: arena_slab_alloc (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2e12b000,= size=3Dsize@entry=3D8192) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff9747, commit=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D8192, alignment=3D4096, zero=3Dtrue, commit=3D0xffff97a7,=20 growing_retained=3D) at jemalloc_extent.c:1003 #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 expand_edata=3D0x0, size=3D8192, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D8192, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D8192, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 deferred_work_generated=3D) at jemalloc_pac.c:178 #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D8192, = alignment=3D2147483615, zero=3D, guarded=3Dfalse, = frequent_reuse=3Dtrue, deferred_work_generated=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D8192, alignment=3D, slab=3Dtrue, szind=3D35, zero=3D, guarded=3Dfalse,=20= deferred_work_generated=3D0xffff986f) at jemalloc_pa.c:139 #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D35, binshard=3D0, bin_info=3D0x2a2200ec = <__je_bin_infos+1680>) at jemalloc_arena.c:839 #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4618, = cache_bin_info=3D0x2a600506, binind=3D35, nfill=3D10) at = jemalloc_arena.c:1034 #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4618, binind=3D35,=20 tcache_success=3D0xffff991f) at jemalloc_tcache.c:238 #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D35, zero=3Dfalse, slow_path=3Dtrue) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 #15 arena_malloc (tsdn=3D, arena=3D, = size=3D8192, ind=3D35, zero=3Dfalse, tcache=3D0x2a2e42c8, = slow_path=3Dtrue) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, = arena=3D, usize=3D, usize@entry=3D8192, = alignment=3Dalignment@entry=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8) at jemalloc_arena.c:1224 #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, tsdn@entry=3D0x2a2e42c8, = usize=3D8192, alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, = is_internal=3Dfalse, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D8192, = alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff9a14, = dopts=3D0xffff99f4, tsd=3D0x2a2e4060, size=3D8192, usize=3D8192, = ind=3D) at jemalloc_jemalloc.c:2398 #20 imalloc_body (sopts=3D0xffff9a14, dopts=3D0xffff99f4, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff9a14, = dopts=3D, dopts@entry=3D0xffff99f4) at = jemalloc_jemalloc.c:2693 #22 0x2a15677c in __aligned_alloc (alignment=3D8, size=3D8192) at = jemalloc_jemalloc.c:2821 #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D8, __size=3D) at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 #24 operator_new_aligned_impl (size=3D, alignment=3D8) at = /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 #25 operator new (size=3D, alignment=3D) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 #26 0x20ff35f8 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:92= #27 StartNewSlab () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:344 #28 AllocateSlow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:200 #29 0x26c0ab48 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:176 #30 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:214 #31 operator new () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:448 #32 getMachineMemOperand () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:496 #33 0x2705c62c in getStore () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.c= pp:9015 #34 0x270941b4 in visitStore () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBu= ilder.cpp:4746 #35 0x2708d80c in visit () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/Instruction.def:173 #36 0x2708c9e4 in visit () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBu= ilder.cpp:1346 #37 0x270f53c8 in SelectBasicBlock () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:838 #38 0x270f4b84 in SelectAllBasicBlocks () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:1863 #39 0x270f1f24 in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:631 #40 0x28300224 in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp:70 #41 0x270efd6c in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:374 #42 0x26c15e88 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:94 #43 0x276a9e74 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1440 #44 0x276b0d40 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1486 #45 0x276aa5e0 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1555 --Type for more, q to quit, c to continue without paging-- #46 run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:541 #47 0x2216d2e8 in RunCodegenPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1157 #48 EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1180 #49 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 #50 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 #51 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 #52 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 #53 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= #54 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 #55 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 #56 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 #57 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #58 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #59 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 #60 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 #61 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 #62 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 #63 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 #64 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 #65 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 #66 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 #67 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 0x2e12afd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2e12afe0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 0x2e12aff0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 = 0xa5a5a5a5 (gdb) x /1024x ((size_t*)addr)+0 0x2e12b000: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2e12b010: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2e12b020: 0x00000000 0x00000000 0x00000000 = 0x00000000 . . . 0x2e12b650: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2e12b660: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2e12b670: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x2e12b680: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e12b690: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e12b6a0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a . . . 0x2e12cfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e12cfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a 0x2e12cff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a = 0x5a5a5a5a (gdb) x /1024x ((size_t*)addr)+2048 0x2e12d000: Cannot access memory at address 0x2e12d000 For #0..#10: The prior examples and the above agree about: #5 __je_extent_alloc_wrapper zero=3Dtrue But also there was in this example: #14 tcache_alloc_small zero=3Dfalse (The others before #14 are optimized out.) So summarizing some of the failure results so far . . . The common part of the call chain is: #0 thr_kill () at thr_kill.S:4 #1 __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 #2 abort () at /usr/src/lib/libc/stdlib/abort.c:61 #3 ehooks_debug_zero_check at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 #4 ehooks_alloc at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 #5 __je_extent_alloc_wrapper at jemalloc_extent.c:1003 (argument = zero=3Dtrue) #6 __je_ecache_alloc_grow at jemalloc_extent.c:126 #7 pac_alloc_real at jemalloc_pac.c:124 #8 pac_alloc_impl at jemalloc_pac.c:178 #9 pai_alloc at = /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 #10 __je_pa_alloc at jemalloc_pa.c:139 Note: some #11+ can show arguments with a zero=3Dfalse All the non-zero Bytes in the pages being checked are 0x5a bytes. The zero Bytes (if any) come first so far. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 14:17:23 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 4dBNpw6l0xz6HmkY for ; Wed, 19 Nov 2025 14:17:28 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBNpv4nZ6z3x89 for ; Wed, 19 Nov 2025 14:17:27 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=AOWwNIRf; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="B H1VCXk"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.159 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id DE93A7A0073 for ; Wed, 19 Nov 2025 09:17:25 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Wed, 19 Nov 2025 09:17:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1763561845; x=1763648245; bh=mje0XiQXPiRs26AOmmNZclDIyC7N8UKM XCboSA3LSn8=; b=AOWwNIRf+WQczNFkedkYUVInzZ1dbIVPMqVrp58ifYxL0fyG ebuJB04zEmYi8AkiEy+EqbN161c41pYW3RJdwLAjDgfrA1ev9KrN65k4hQDChqs3 6i1xGYGRXPf0GKpouVHlkviOzC9tSv/s1zB47XlbDDx86X3wXc0nrusC8LxNvr5g 6XwtDwrITHpYVoAY+z46VrsOBZmu5CGFKJJS8NQDtefCfXHLRYPsQgENVPhAeuqh S2skRI33F9KYCOiv/uxermSu/FpuIp5z+QeJYeUtPfMDmnK50MVwXXAw5Wf0WZER ArpzP117F9H5LqhFuRIeuyYdL5N5BYabaEF+Tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1763561845; x= 1763648245; bh=mje0XiQXPiRs26AOmmNZclDIyC7N8UKMXCboSA3LSn8=; b=B H1VCXkvDqF5aY5jULaKBlOfJPJlxR/6Dcbl6s4iu/DuJzWX0uk8o0QU9zsmwBLwt CYAg7U/roj01qXMreBPL2hUhgQwE71bDv084wlMCTy+aGqA9LX2ZM4NL15ULDmc8 VgeXPkmT6k3tAToJxCfbiCpi2+ZInLer5EukMowWakzBodKSVG2hisiqpcVtsc5y F2hxXh8VCzivd067VWhNAEkzNnevSm6r5f41KCLnFG5lBmOxgnqn9X/q5uWIIkhL VnDEiJvwhvI/8kDBb3gZtcuvRRfafW4BEKizIxhiiVf3NnbFz1/aLWXBe3J6dkHT Afut6LRCN6AkvsaKzW+2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdeggedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttddtvd enucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthhtvghr nhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegffeune cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgu sehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtg hpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 19 Nov 2025 09:17:25 -0500 (EST) Date: Wed, 19 Nov 2025 14:17:23 +0000 From: void To: freebsd-current@freebsd.org Subject: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org 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; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.59 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.993]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.159:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dBNpv4nZ6z3x89 Hi, A newly installed system was installed with pkgbase It was then upgraded via source with git. This is very recent 16:current amd64. When it came to installkernel, it was suggested to set env DESTDIR=/ which was done and then installkernel proceeded normally. The same thing with installworld. My question is this: does this need to be done every time from now on, or does some setting/tunable need to be modified somewhere to properly un-pkgbase things? -- From nobody Wed Nov 19 14:42:22 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 4dBPMp2HFsz6HpF7 for ; Wed, 19 Nov 2025 14:42:30 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-24424.protonmail.ch (mail-24424.protonmail.ch [109.224.244.24]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBPMn6HHmz44KG for ; Wed, 19 Nov 2025 14:42:29 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=2ixcxu4rkvfldf3ir2rtvgj7ue.protonmail; t=1763563346; x=1763822546; bh=mHJWTIrHwuVbWKMquxhoXXX6TKuBc5ODJGUaY1nPmmw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=WPu3/yllxGF3Y8+NqGeUuRPFmtFVvCN7sVsUtnqHohgXTn8Z34lvYiuQFU/jnz1Bg aQUuK+z48swNOj8RsHfxoJWF3IF2vTZpuyOo2x2D2VDQng7Azs3/PXLx4HSLY2VmNN gQYQRLnZYZEleqKMk6gAYVsJrkeo3xu7UQWE8xnNzCXqrVwpwq5sKUJLQ7X056z+pH 7vVtaUE+I9eLA12Bx604nJZU4ZvBmOGw2743cNWQD5eAbPG/9sR7V3/Pv6yeKYJtZZ QviTqOlYx+wEajlMzDLvn69TKSIfyeeSqorgu6B4AaWs3OqobQcDEq43HZODEvUwpA +Si4sMFuq/aEg== Date: Wed, 19 Nov 2025 14:42:22 +0000 To: void From: Minsoo Choo Cc: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: In-Reply-To: References: Feedback-ID: 45891198:user:proton X-Pm-Message-ID: ed3593ddbc724ecb79fd24fc5a822dcd5dfc5117 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBPMn6HHmz44KG On Wednesday, November 19th, 2025 at 9:17 AM, void wrote: > Hi, > > A newly installed system was installed with pkgbase > It was then upgraded via source with git. > This is very recent 16:current amd64. > > When it came to installkernel, it was suggested to > set env DESTDIR=3D/ which was done and then > installkernel proceeded normally. > The same thing with installworld. > > My question is this: does this need to be done every time > from now on, or does some setting/tunable need to be > modified somewhere to properly un-pkgbase things? > > -- By "suggested", do you mean it is a warning or error? In either case, I thi= nk DESTDIR should be defaulted to / without printing any message. Could you send me the output (where to suggestion occurs) so I can investig= ate further? From nobody Wed Nov 19 15:02:47 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 4dBPqG3rhkz6Hq8H for ; Wed, 19 Nov 2025 15:02:50 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBPqF6PwRz47Y3 for ; Wed, 19 Nov 2025 15:02:49 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=gsrYNDNF; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=twpYc02D; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.151 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id 508871D0011D for ; Wed, 19 Nov 2025 10:02:49 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Wed, 19 Nov 2025 10:02:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763564569; x=1763650969; bh=WWUZhx9cP0 nR2oMXptsRT5dyP6PRlj39xxUO2Wmv11s=; b=gsrYNDNF/o7fH6L1Am2JX5SUiE Dp7V+fDTaFIIn6fMKXoTdaY6woJ8ClcZ0EnWBT/igI7alZx8X6hdtDvC5HrWTpOr fcPS4L40DKwJkrd4wrBHoDs6U38zu49rkg9USrKXNOuyZOMmmQhjO4hnom04FxXU gwj3X5UcR1HyxhCMr/YVPru9PlQQYrzqbni+CGKt4Tdr6Y4u4uNICjZb4t3dEVaH MggkWL/uNiDW9Sm2tHTe+j728OuNvppLI3ucDmbJWtNsJH4KDu+j0Br0SWhUPiZD OBAuYSQ5SSnH5mSVlz+Pq8Dh5wh4uGm/hkToZhE8rTbRt9aWXUjpaSmKgr/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763564569; x=1763650969; bh=WWUZhx9cP0nR2oMXptsRT5dyP6PRlj39xxU O2Wmv11s=; b=twpYc02D+Vi2qYCzrFkYa0Rs2asY2gz4q40RmMcdUZdueRH9K0r jhzT9ky3F+7KpXL9Fu/NsAf9qyK4GJ7BLZ2P+H3T514KxWSR/Na8xxvNr93yBjPy nva83z19rHX3PaojlJSGIG5fCRtKpdp3VKUfVRFOVViXwg/hXP3N1NPp7+k+NVeN 8kS4NOyZaEY0aGWA3WO9nQx0YUuvHkYusDfXUhBJPoe8eQWjKRoIlqXLH8WbhN2Q u+sYSOGEL7oupXSwoz030fIP4ES2kdlvzwMHH4jbfcNljtqNpkHmP41VlUZuFjjk W5fcEQQlhIvs7VAJy3O0x7VdVNLN973AM/Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdegheduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgf eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 19 Nov 2025 10:02:48 -0500 (EST) Date: Wed, 19 Nov 2025 15:02:47 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.46 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.859]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.151:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dBPqF6PwRz47Y3 On Wed, Nov 19, 2025 at 02:42:22PM +0000, Minsoo Choo wrote: >By "suggested", do you mean it is a warning or error? In either case, I think DESTDIR should be defaulted to / without printing any message. > >Could you send me the output (where to suggestion occurs) so I can investigate further? It's an error in that I couldn't get past it unless DESTDIR was set to /. I can recreate the error on another vm, but it seems that in getting past the two errors, I have partly answered my own question in that the error does not present itself any longer. Give me a few hrs and I'll be able to regenerate the entire error message from a new vm. In the meantime is there any other information you'd like me to get? -- From nobody Wed Nov 19 15:14:28 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 4dBQ4s1jkWz6HqxD for ; Wed, 19 Nov 2025 15:14:37 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBQ4r4PjQz49rt for ; Wed, 19 Nov 2025 15:14:36 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=lxnqyoedqzho5as64pe7oowaqy.protonmail; t=1763565273; x=1763824473; bh=rY8t8UdoPbTzGUWAVUnDgP6YF5g5dWgEP8TOM8nRGUs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=JNegs9YdU56rS4nkKRzsg6lOsKjDtSVlZZ0Iwr301B4qsSpVpBoVf9uYQ2vglVqhc nw+5zSGrczvoXG6YM1ndtChfvODh/1QHyZaiKavCo8ufM8vRTnCm81PEkTxtFnWX1t Q4krcvCflwl2SBtbnZmGf7CpdT82wWqZC6Y7XYslNLls49iZg0pJlZ4Y1VEqRPOC9v l4UxY1/f6nmacnxmHk6v7fEQ6w2zFGbSXZDDUN4MxxoJ1wkUFgfUr2UZaHlwjE4alB HeF24wTl9+x9qlcXxHnIKlJMuKZa8vRWNyqUzgOzSXMuJuNS8pIEil04zNl6MCPYIw cbLKmJ+Lje72Q== Date: Wed, 19 Nov 2025 15:14:28 +0000 To: void From: Minsoo Choo Cc: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: In-Reply-To: References: Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 97cb926dbad98880ce7ec18473b0ebc2c39c052a 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBQ4r4PjQz49rt On Wednesday, November 19th, 2025 at 10:03 AM, void wrote: > On Wed, Nov 19, 2025 at 02:42:22PM +0000, Minsoo Choo wrote: >=20 > > By "suggested", do you mean it is a warning or error? In either case, I= think DESTDIR should be defaulted to / without printing any message. > >=20 > > Could you send me the output (where to suggestion occurs) so I can inve= stigate further? >=20 >=20 > It's an error in that I couldn't get past it unless DESTDIR was set to /. >=20 > I can recreate the error on another vm, but it seems that in getting > past the two errors, I have partly answered my own question in that the > error does not present itself any longer. >=20 > Give me a few hrs and I'll be able to regenerate the entire error > message from a new vm. In the meantime is there any other information > you'd like me to get? > -- Thanks for your effort! Since DESTDIR has been around for some time, I think the related logic was = accidentally removed while adopting pkgbase. This won't take too much effor= t (just set DESTDIR to / if it is not specified), and I don't need other in= formation for now. From nobody Wed Nov 19 15:54:38 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 4dBQz638qPz6HtTP for ; Wed, 19 Nov 2025 15:54:42 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b1-smtp.messagingengine.com (fhigh-b1-smtp.messagingengine.com [202.12.124.152]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBQz54yLbz4H8h for ; Wed, 19 Nov 2025 15:54:41 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=L4R7japG; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=xfElPBtR; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.152 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id 990857A010C for ; Wed, 19 Nov 2025 10:54:40 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Wed, 19 Nov 2025 10:54:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763567680; x=1763654080; bh=hZ3xTY2+oC HbkFgT1MBt3wtpKkrEj7pidYOqS7Y7ha0=; b=L4R7japGHGLDay/sWtnFPIl/va Z6VhlpC+92FVIDPRsdC6ANB24F7hOfRdfZTPkwk4fuP7XiOuuAZFG9vQ6Vo0ad05 jhEL5m+Uyl82jcYbZpi2rpRW5oKlpwmRdrAsKnCvfkpPDWHqKY/HKLWgT/jTM5dl XxoqrUi088vbXrJ73reVQ18p1ZKwTik9aMy3EKcgonK1HeHT2Q5vcQ5z1CSp16Zq R9DqNJPRWOVbNqSz0KN4LZiNDSs2ZniGZ5vH0dkgQxRwus1D1lLl+ELI1LsVfI1N zwg0+ix9yjBc1trsqG6Wz1RBhnI/6JKarNEzZRYM/RfjC5p55RqGEJWPRcgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763567680; x=1763654080; bh=hZ3xTY2+oCHbkFgT1MBt3wtpKkrEj7pidYO qS7Y7ha0=; b=xfElPBtR6phK9RGqjv7nQJ7xpROo00/q1sJW6uo795omQRewK/p YpYh2gulWyQrEzQ8m7wf9DjFa8YoJ3osAYlMbMScJLzGSat46qpPyUJBVSw5GN1v Rds2pAQXEhaMCt4lF97rJ5ZGgOtusnsK/WPsX6dMW0vqKO/Ww9rRhFghOKGJi+D6 A1KFtRpeLCi3x7klH81EpG3bj7AGPZykFDKJvP0WErqaIlUKG4XBrUU/N5/n5nQZ OJzfPj6YK8Ucmr7aiojUhg3kdnakSbaZbBSmUbITt5fU8GbkJJgHI8fflwH5FvDT mlj0884vwonoeRr/dhcPz8UwzrwCcYNfl5w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdegieduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgf eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 19 Nov 2025 10:54:39 -0500 (EST) Date: Wed, 19 Nov 2025 15:54:38 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.57 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.152:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dBQz54yLbz4H8h On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote: >Thanks for your effort! > >Since DESTDIR has been around for some time, I think the related logic was accidentally removed while adopting pkgbase. This won't take too much effort (just set DESTDIR to / if it is not specified), and I don't need other information for now. What's installed: FreeBSD-16.0-CURRENT-amd64-20251110-dbb34d496708-281771-disc1.iso % doas git -C /usr/src rev-list --count --first-parent HEAD 282028 root@fbsd-16-main-ufs-2:/usr/src # make -j16 buildkernel -------------------------------------------------------------- >>> Kernel build for GENERIC-NODEBUG completed on Wed Nov 19 15:47:11 GMT 2025 -------------------------------------------------------------- >>> Kernel(s) GENERIC-NODEBUG built in 928 seconds, ncpu: 8, make -j16 -------------------------------------------------------------- root@fbsd-16-main-ufs-2:/usr/src # make -j16 installkernel --- installkernel --- --- __installcheck_PKG --- ERROR: This target should not be used on a system installed from packages. To override this check, set DESTDIR=/. make[1]: stopped making "installkernel" in /usr/src make: stopped making "installkernel" in /usr/src root@fbsd-16-main-ufs-2:/usr/src # -- From nobody Wed Nov 19 16:14:27 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 4dBRPz3qvpz6Hw53 for ; Wed, 19 Nov 2025 16:14:31 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b1-smtp.messagingengine.com (fout-b1-smtp.messagingengine.com [202.12.124.144]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBRPy45R8z4MLj for ; Wed, 19 Nov 2025 16:14:30 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=HoM0bZsl; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=eLAAjnnu; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.144 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id CAF6A1D000F8 for ; Wed, 19 Nov 2025 11:14:29 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Wed, 19 Nov 2025 11:14:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763568869; x=1763655269; bh=vk7ec7tPR6 7mwVWcm9yz5U24nzVPx0L9OMrW0c0qsn4=; b=HoM0bZslhiDOjktx5z7AgjZFh3 H3+Fy8CAMV9W7CO008SW6C/EBWuWHJ6+C64lfiYOAzFsufc/PVdkNmUlMgNszQ4J I1FgVdzU4gVVZg7nKK7nTiNt8wmPRvNYb4cvBb46ZqV1cVFeu3XLgHtGPb5W4mDD bFUQOPLWb1d/cArjZpD99M6+8tsnFca7Rh5E9zC5WYn0/0Vh6G8JZWyShVPxksQq PQKEbvx7ZeDHEV6jFe9FXH29sr4ro9tT0JjTiJGmXQBwhCRzpjdJFdExn63RwPko 71ELDoJwrQLkGXY3c4/e7A0YBg5/ApaYkNC3WrL3a6bMECo4ueXihQhiydgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763568869; x=1763655269; bh=vk7ec7tPR67mwVWcm9yz5U24nzVPx0L9OMr W0c0qsn4=; b=eLAAjnnuInfRMd8+ONh3QiKty+7vua587GV7Yem3unk0x5rUqUo 08zjSW6gkE3G398nvMlaLeA7MZy67NOGgw76t5rYbmWch9lpw0dIk0IIL+QP68iH 8DpQiL/kIZyQ6OS5O0HsoAgdZxd9BD5OPjTqFkxg52+518QYqtHY9kV7Dmrmctt2 wVEgJE5cUfaXPonovMF039v3g4wIb3F+LbU5XpeZAuY6gqVIgOYJJsT6czqn8yIJ +bZQ3fddRH55igDZvnwC5CxjTiFXmLNi5KM2cK+cUjX8io7n1nlBCDC+zelyijzp LXSqKRMXqcb2fOW5hksyS8oBPxxV0ZAVfww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdegieehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnheptdfhheeuteejudffkefhtdfhfeekgedtvdeiteevgfejtdfgfeffhfeuieeltd einecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtg hpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdq tghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 19 Nov 2025 11:14:29 -0500 (EST) Date: Wed, 19 Nov 2025 16:14:27 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.53 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.932]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27:c]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.144:from]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dBRPy45R8z4MLj On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote: >Thanks for your effort! > >Since DESTDIR has been around for some time, I think the related logic was accidentally removed while adopting pkgbase. This won't take too much effort (just set DESTDIR to / if it is not specified), and I don't need other information for now. I think I've found the reason for this in https://reviews.freebsd.org/D52879 which I didn't see before. There should be IMO a setting or a sysctl or something like pkgbase.enabled=0 though (my own perspective as a user) -- From nobody Wed Nov 19 16:25:20 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 4dBRfY4mGHz6HwjP for ; Wed, 19 Nov 2025 16:25:25 +0000 (UTC) (envelope-from grembo@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 4dBRfY4DXJz3D8b; Wed, 19 Nov 2025 16:25:25 +0000 (UTC) (envelope-from grembo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763569525; h=from:from: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=XoARTNR9Gp9wOqUzfRHbcnZ8XIttw4GIcJ6YyFI0xPk=; b=dZ/Wy/w3A+qu6Sc3RoYupI+K7Y2gJnYZZUXXDIMiUpJy55KJBvZlkdQxbr/gB5Kvju0LFt fybGRZj3+ONF3nho96LXaw5Li+2Yb9dJMvPkgyRPmZjcNHrR+KvN5e0NyUvvD1pp9ajoc7 OAGKmct9+R3gx5KaLUPjxDTrJsv6URsjy/Cs+Wd91OJo7WUt/RlMTAhM5P9zXiEZOAwdMy VUDhryUDnnc3KFDtW07S14+g1dilkrDMGqxoJ5eCf2XpFQeoeNR/bH03rX9/u4w2rU3GbR 47qGztO/BJ/Bxs8i/9MOXlh7S5jfDFAFHvHQAJbGuptjQiAgjjHW/xh3T4J5SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763569525; h=from:from: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=XoARTNR9Gp9wOqUzfRHbcnZ8XIttw4GIcJ6YyFI0xPk=; b=tBIXzSXJHNckWCNoptWbz1YbGM+LWd6Xd6pHy+T72Z4o0vbcuA9/jAkkLG53Oallv2nCpS XpVdi6vUA4k5jleacR7jgYpCsCa+6n5CdOLnE4lfgNgvmdDY/4fuRrQ+A+g8ae5jvPQ6KZ w4J9OSW8kuXsrj1ODHpC7ltz9TCQJ94k9DPf57RDzFX0FZtv11WDRByRlWcf8+L7Y84Es6 o96N9i71ag1CSROW63CAO2lzgz92umy/9doMEJQoFeehkRasIB6gnlpbb91ZI5QU6IqPHL 1ilGZoocAEMQZs/H4WCNBfu6u6qioQPgmW6uMj5XNDgP/yIvwXuJvtfwKcgVCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763569525; a=rsa-sha256; cv=none; b=VAGx6ifnJk8Iw5hC5oX4HLtLRYVKQ31lFeDo0ONmpdTfEAOh3E+Bq1pqf9eWGCeBlsvWBx WEMOTyOZ5B6yaVQaAh6WEWhmSb8sjppR3CSA/6SZlFr3t+gfBPXnxSovygYi/7c1BvKuD0 A57msriEY2o+gcs8VYPN12doCGQ7ga92OI3UttIr6xAfeOy42rkeNjk1YHOJNCTY048Xnq h9AH8o3ijWFzB+JkUYCeCRiQBpzRsSIDfKpelwHadeKkQsDCq3PNDjzPrvCZm0ulNw+roJ JWBd8PQ2rQ5EVfQpK4aAy5/BpMRn8hltZMF4Hiu9wPaKtYIOF0K07Fipkw/k0g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: grembo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dBRfY1DrYzFG4; Wed, 19 Nov 2025 16:25:25 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id e1140ddd (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 19 Nov 2025 16:25:23 +0000 (UTC) Date: Wed, 19 Nov 2025 17:25:20 +0100 From: Michael Gmelin To: void Cc: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: <20251119172520.4af73dd0.grembo@freebsd.org> In-Reply-To: References: X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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-Transfer-Encoding: 7bit On Wed, 19 Nov 2025 16:14:27 +0000 void wrote: > On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote: > > >Thanks for your effort! > > > >Since DESTDIR has been around for some time, I think the related > >logic was accidentally removed while adopting pkgbase. This won't > >take too much effort (just set DESTDIR to / if it is not specified), > >and I don't need other information for now. > > I think I've found the reason for this > in https://reviews.freebsd.org/D52879 which I didn't see before. > > There should be IMO a setting or a sysctl or something like > pkgbase.enabled=0 though (my own perspective as a user) What is the procedure to run a custom kernel with pkgbase? In the last couple of years we needed stability patches (pf, zfs, etc.) on almost every second release (at least temporarily, until an errata was created). Would we need to run our own pkgbase server in this case or is there another (non-hacky) way? -m -- Michael Gmelin From nobody Wed Nov 19 16:31:13 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 4dBRng6BXBz6HxGX for ; Wed, 19 Nov 2025 16:31:35 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBRng0sLQz3FQR for ; Wed, 19 Nov 2025 16:31:35 +0000 (UTC) (envelope-from fjwcash@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-433791d45f5so51754925ab.0 for ; Wed, 19 Nov 2025 08:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763569886; x=1764174686; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dOax16Z27juNay9fZeloD4hRu96oI9qs/yGcTfYnNhM=; b=cerXa4adlcmz9bdOrQZSXmDniEueCpgTXIG2oC62k7OED4mL6ZZaNrhTbqunXOuujK wkJGEN6sMuQ+pz6xVMJneWVKjOBGW9dmruSDu60e0fhcG/q3B3F1P64T5mgGxLVYYkdy 61XurRZKVRdfy5vkPZDSVO+lPDZ/0BSyQLQDHY5/pANn9PfBxIIuXqSNWusPVpw10kPC kFxGwCD+OWI8gDgn+36EJvA23fYD7GtFfpT2AdhrvSGtP4sFPx+j5VHxHwkWM/kBdxG1 kcQTLQNYmOOGlWHPI5rkkAgNEiDOcBT7jrk6+SMivZZW9nE32DN0n8iA5B/skUUMIQfm T4+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763569886; x=1764174686; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dOax16Z27juNay9fZeloD4hRu96oI9qs/yGcTfYnNhM=; b=Fnry96rEvhSq5WxgxzRtOQeQuaMGUbsPgK7eEacDPekJ8Td1QobC72U1lpOmKgWxDC 8jbQaY+6Zt6KmEsBupQcXGfNPNhYiijjE+uTpRCHuGWu+smWFfle9JAgelFo73qiengb tA6rgjdBlRl1s6JM6mzO5+q8tnUE8nGWvcJWTkLX6QN1ZaZvI9y/E6cX0JWYFoDFUfNo RgK7JTwdeX/tJjj4Phzd+GqLIHqlzm+iLSzfo/Yj/5254mXBFI90FcUYsduvHaOUfX20 FWAxO3dI9uumjWn5iZFO/VFwAWh11hDOUHle9zoiURVsKNvAl5fI5BjOKNGRquDd3IV3 zJAA== X-Forwarded-Encrypted: i=1; AJvYcCVm+KAx+K/sOP+O1X6wP9tv9pRiVKDpTpkkR6D2f0OIaIB1IepsUcGUmRbuTXmYPndpVQw4WEVIlOzFG6JXcD4=@freebsd.org X-Gm-Message-State: AOJu0YxQxwq9Vx28ctos2EA70zZfmZ3mgpDA7/C065Dt7wGAP7deskzU ISZUtex8wXQ1oIImmh7dsuMLapJTnZqhn67Z90EeZTcpD5vGGoR4axPHiulfCZf8HxPxwh6SzLO bJPKGZAgIJdE4IZ+JMrK0y3Y5fzq8SDg= X-Gm-Gg: ASbGncv2qyOM8KuAQQOGcRy6xXDOzBGwLF8Nd9Q7cbAJfY2psCZaNG2AMtaHwK0E2ME sVex5GwQD20jwaULpIATBjxli/bHsVK1sAZUmP7tqrFjjUjw/FiQXYV4Oe74FhugYvt9vwCX+mH Nq3RMc+RAxj6MI/dYtljBcUKiLmomUAtWqVBRTsWtY+Zf09IxGNwxyDWF8g+S9sqJuDh7lnB+P5 mkpW6xIh/D8iy0JlrwUzlTzjd9JnlqEVuPRpjok7g86rTyMwiU5scjzX5tKdTq0XiMpL8LfwvEJ mZ+bNQ== X-Google-Smtp-Source: AGHT+IGuALLkxSj8ZHE8il5nPtMYnDpmcPjq/tOPWK2GuBPk1KooW0j+3VDqU4H2/QuXlUkBWFxnYPonVi+Wo1fu6og= X-Received: by 2002:a05:6e02:1582:b0:433:2c61:b483 with SMTP id e9e14a558f8ab-435a9074318mr757835ab.25.1763569885298; Wed, 19 Nov 2025 08:31:25 -0800 (PST) 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 References: <20251119172520.4af73dd0.grembo@freebsd.org> In-Reply-To: <20251119172520.4af73dd0.grembo@freebsd.org> From: Freddie Cash Date: Wed, 19 Nov 2025 08:31:13 -0800 X-Gm-Features: AWmQ_bkKiqvzyCM497l2vrfHsyibEWJjlT0cXwBGONYw86u2ADL6XTPSiKfE15k Message-ID: Subject: Re: changing from pkgbase to regularbase To: Michael Gmelin Cc: void , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000008cc2230643f51c92" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBRng0sLQz3FQR --0000000000008cc2230643f51c92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2025 at 8:25=E2=80=AFAM Michael Gmelin = wrote: > On Wed, 19 Nov 2025 16:14:27 +0000 > void wrote: > > > On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote: > > > > >Thanks for your effort! > > > > > >Since DESTDIR has been around for some time, I think the related > > >logic was accidentally removed while adopting pkgbase. This won't > > >take too much effort (just set DESTDIR to / if it is not specified), > > >and I don't need other information for now. > > > > I think I've found the reason for this > > in https://reviews.freebsd.org/D52879 which I didn't see before. > > > > There should be IMO a setting or a sysctl or something like > > pkgbase.enabled=3D0 though (my own perspective as a user) > > What is the procedure to run a custom kernel with pkgbase? In the > last couple of years we needed stability patches (pf, zfs, etc.) on > almost every second release (at least temporarily, until an errata was > created). > > Would we need to run our own pkgbase server in this case or is there > another (non-hacky) way? > There's a make target for building packages for installation via pkg using the sources under /usr/src. I don't recall what it is offhand, but it should be documented in /usr/src/ Then you just install the new package for your custom kernel. --=20 Freddie Cash fjwcash@gmail.com --0000000000008cc2230643f51c92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 19, 2025 at 8:25=E2=80=AFAM M= ichael Gmelin <grembo@freebsd.org<= /a>> wrote:
On Wed, 19 Nov 2025 16:14:27 +0= 000
void <void@f-m.fm&g= t; wrote:

> On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote:
>
> >Thanks for your effort!
> >
> >Since DESTDIR has been around for some time, I think the related > >logic was accidentally removed while adopting pkgbase. This won= 9;t
> >take too much effort (just set DESTDIR to / if it is not specified= ),
> >and I don't need other information for now.=C2=A0
>
> I think I've found the reason for this
> in https://reviews.freebsd.org/D52879 which I didn't = see before.
>
> There should be IMO a setting or a sysctl or something like
> pkgbase.enabled=3D0 though (my own perspective as a user)

What is the procedure to run a custom kernel with pkgbase? In the
last couple of years we needed stability patches (pf, zfs, etc.) on
almost every second release (at least temporarily, until an errata was
created).

Would we need to run our own pkgbase server in this case or is there
another (non-hacky) way?

There's a = make target for building packages for installation via pkg using the source= s under /usr/src. I don't recall what it is offhand, but it should be d= ocumented in /usr/src/<something>

Then you j= ust install the new package for your custom kernel.=C2=A0
<= br>
--
Freddie Cash
fjwcash@gmail.com
--0000000000008cc2230643f51c92-- From nobody Wed Nov 19 16:36:52 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 4dBRvy42WZz6HxQv for ; Wed, 19 Nov 2025 16:37:02 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [31.134.205.98]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBRvx6XbHz3GHq; Wed, 19 Nov 2025 16:37:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from crmpreview8.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview8.colo2.realworks.nl (Postfix) with ESMTP id 6B6DC2C02A3; Wed, 19 Nov 2025 17:36:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1763570212; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=Pd/Cl4N6gIrL6Rlyw2+oCPAfFW1Or35GliMKQJ1pvHg=; b=PoRVNRhArxNvDAZeeLuKlmGMy1YRQ6PSpY9oQcbnLOLQ5840FTE8d0qw+NDZktcSjfYKij 0hIggKpc3r2fR3qOhvq1vntDLWNaIM5LYUr7tbeLRfGyHDhUFvUCQ3PyEsd28Ed66UJLOf 63/fuFiuqX1p4zKLuAGp6diTifnqkMa7KbD7s8iIEfndr5WgKRHw/hdWxoZf3ApGCjOsGn RV3iZ3l+pMNmpcPjIGGRWP8N1AQgr+k8vQSd8L7pjEkvq85bO3eHgOLjKJuuhHxTN1GW35 2qxJND0IQVVFqNHuo8O6WI+ebq7+WlO6kRU+zUj47QSuVIB9DYe2mCdxnGAXGA== Date: Wed, 19 Nov 2025 17:36:52 +0100 (CET) From: Ronald Klop To: Michael Gmelin Cc: freebsd-current@freebsd.org, void Message-ID: <956876364.10101.1763570212151@localhost> In-Reply-To: <20251119172520.4af73dd0.grembo@freebsd.org> Subject: Re: changing from pkgbase to regularbase 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: multipart/alternative; boundary="----=_Part_10100_1925071025.1763570212148" X-Mailer: Realworks (773.20) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:51088, ipnet:31.134.200.0/21, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBRvx6XbHz3GHq ------=_Part_10100_1925071025.1763570212148 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: Michael Gmelin Datum: 19 november 2025 17:25 Aan: void CC: freebsd-current@freebsd.org Onderwerp: Re: changing from pkgbase to regularbase >=20 >=20 >=20 >=20 > On Wed, 19 Nov 2025 16:14:27 +0000 > void wrote: >=20 > > On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote: > >=20 > > >Thanks for your effort! > > > > > >Since DESTDIR has been around for some time, I think the related > > >logic was accidentally removed while adopting pkgbase. This won't > > >take too much effort (just set DESTDIR to / if it is not specified), > > >and I don't need other information for now. =20 > >=20 > > I think I've found the reason for this > > in https://reviews.freebsd.org/D52879 which I didn't see before. > >=20 > > There should be IMO a setting or a sysctl or something like=20 > > pkgbase.enabled=3D0 though (my own perspective as a user) >=20 > What is the procedure to run a custom kernel with pkgbase? In the > last couple of years we needed stability patches (pf, zfs, etc.) on > almost every second release (at least temporarily, until an errata was > created). >=20 > Would we need to run our own pkgbase server in this case or is there > another (non-hacky) way? >=20 > -m >=20 > --=20 > Michael Gmelin >=20 >=20 >=20 >=20 >=20 Instead of make installworld you can do something like make packages to bui= ld your own packages. NB: I don=E2=80=99t know the exact syntax from the top of my head. NB2: Poudriere can probably also do this for you and integrate as a local p= kg repo. Regards, Ronald.=20 ------=_Part_10100_1925071025.1763570212148 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: Michael Gmelin= <grembo@freebsd.org>
Datum: 19 november 2025 17:= 25
Aan: void <void@f-m.fm>
CC: freebsd-current@freebsd.org
Onderwerp: Re: changing f= rom pkgbase to regularbase

<= div class=3D"MessageRFC822Viewer do_not_remove" id=3D"P">


On Wed, 19 Nov 2025 16:14:27 +0000
void wrote:

> On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote:
>
> >Thanks for your effort!
> >
> >Since DESTDIR has been around for some time, I think the related > >logic was accidentally removed while adopting pkgbase. This won't<= br> > >take too much effort (just set DESTDIR to / if it is not specified= ),
> >and I don't need other information for now.  
>
> I think I've found the reason for this
> in https://reviews.free= bsd.org/D52879 which I didn't see before.
>
> There should be IMO a setting or a sysctl or something like
> pkgbase.enabled=3D0 though (my own perspective as a user)

What is the procedure to run a custom kernel with pkgbase? In the
last couple of years we needed stability patches (pf, zfs, etc.) on
almost every second release (at least temporarily, until an errata was
created).

Would we need to run our own pkgbase server in this case or is there
another (non-hacky) way?

-m

-- 
Michael Gmelin



Instead of make installworld you can do something like= make packages to build your own packages.

NB: I don=E2= =80=99t know the exact syntax from the top of my head.
NB2: Poudr= iere can probably also do this for you and integrate as a local pkg repo.

Regards,
Ronald. 



------=_Part_10100_1925071025.1763570212148-- From nobody Wed Nov 19 17:08:58 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 4dBSdH1ycCz6J0Qn for ; Wed, 19 Nov 2025 17:09:23 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBSdG1zxwz3LDY for ; Wed, 19 Nov 2025 17:09:21 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=Yp+aB1sK; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1763572140; bh=lfR15vuC2Y5VwOpvzhfR9XcPydVsUxGiKHp0ouBxKF8=; h=Date:From:To:Subject:In-Reply-To:References; b=Yp+aB1sKaAk5EwYhzq8Qa+WjR0tNFxfBaa+Q6kSBuMAFtBBmMmin478UsKwKgjqEu IjNmvf8NlDj0KvJWbsFNormML+RQzdkWolKRX2YPnnvDWoH8EGoWFFjaiW/lPG92Gg pvC0EAlrbjtz/6DV5dbdXkqpJeF7N99pHIBq3fUibwEIm7SeUFvEYuhGqQMAAuaOZB bp4Tefmubn4X9aBwgUH5TuVFki7h8sJBkrMK9eooF73rARguafePakvCoJgVCjrJ/x RB2kDaRj+fLGh2MGaw8WRokQ/Zg3NnrpTBEp59GVuLfgOGKkX0wGy7Td/F+bldA5m6 gsayrPk/7zFUinO/XX1/OVH9cfY2FEbeqphiEH9Hn5Nqm1whePpj8BNUrDQDlrmJqO /8bGCbJQ3X5FBRoxnx2VPP5uxdnGYSc0Rso7IA7LvlpcQfSnLpNJ6obTudXXBNiCbN h+Xn16mAScLca6VZnWhAUs7GMgYMhMI35d7lGMzt2AsJC3FLv2owEWZ1a99ZCfDPkH RaxHGbudh9wuj9U1KV0yhO8LBbxL9LvmYcT2LruSv8Ms32jlF14UoptYZdv2sWseQJ AQ4yG7cfFyCGrIDAOgAsSnANGQEC7S5H6snMQX54Mh6yXiMyB2B/1GyHI6riZJbxNC i6vgHZDs1y9GDmNXZGlJEPXI= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 1A70E5D56FB for ; Wed, 19 Nov 2025 19:08:59 +0200 (EET) Date: Wed, 19 Nov 2025 19:08:58 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase User-Agent: K-9 Mail for Android In-Reply-To: <956876364.10101.1763570212151@localhost> References: <956876364.10101.1763570212151@localhost> Message-ID: <85F1AEC3-5049-4288-BE86-9D06F7B119EF@ketas.si.pri.ee> 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Spamd-Result: default: False [-0.76 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; NEURAL_HAM_LONG(-0.98)[-0.978]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4dBSdG1zxwz3LDY if one needs patches all the time, it could be easier to just make own repo tho, i bet you could just install only kernel from your repo you can also probably build just kernel and not anything else and then jus= t have your kernel only repo and one could "ssh b pkg add - < a=2Etxz" or "ssh c cat a=2Etxz | pkg add = -" adhoc add it without "server" From nobody Wed Nov 19 17:53:13 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 4dBTcJ1lqgz6J3DX for ; Wed, 19 Nov 2025 17:53:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4dBTcH2rLhz3R3q for ; Wed, 19 Nov 2025 17:53:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kBjsGHaV; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763574807; bh=gxddHr+OizQhZcDHvc8T1m+g+5kICsIZBOPykWietJs=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=kBjsGHaVlHg9TPDtzV9IL+yGVtIH5UgmkBUmSoORaeOZQrRN0mgGTLn2LUnN3UqVus1eAalCPhjQqBIAF5xpzjwtfXAPlCRfDIwPRI7fWi1XpH7k5mCsOEXME/R36UH2UIAkApE+/Kc2SxOrGn8j7DoLuusU672fJPP3NzV3TRTncoe1cbMNbshn6zJ8jBDukgU7VniF1+TqVcxrPef1Dd7I4qFmsJ7DBmj9x1xixzQEjIsX1zoCUCQjhMznsHeO6JigF1rG0U7MkrVyp/0b8EdqiA4j3N/lBgzeEWxMNBVIaKriLiLIpfb+mlpwD+7tO7tbLf/+LJ6fl3MdoMpYdw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763574807; bh=LW3M5MCXej7bL4PlJmTi3jjcLwuXLP1xFQjfyabbwTw=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SXmHf5uD0GLaGosz6aEU7wXaV1INZLOd2X70wjOEE0LjGaUQAVIiEqjkAWg93OGoz+8XOP02NUaaygUR3WnEBZ8wpTnD3nwmzldc7P2Rt2EeN+r2HOT5l/CZlvVI+qngadlzXc8KiZuK6xREATIOYzbs7w5U+KpKGDTsta0P8+c82M36LDTa5ctkArP2Rh009L/acpLWz8zYmirAAQlgrpkwNhodL9er2iE7SCz/Ud/ta45oWBatI2WLoirHqupb8HUKbhSNg2/L6hPyC03RCaP5VaJ8gfx31FrUEHqXkCtUPXQpSbNodBkFU4UJdpm5wvLsPf0eBuEor85DjJhdxQ== X-YMail-OSG: Uzwjcr8VM1lZtQAEjuYuJsbWf9nfrQ1Jcto5JDZoXHYvSBztZq0eZndHPlc1_EG bA0t07JxUDejd_Mxwgw72X6In.2s8bqDGR0M5P3WHJ8JJtTW4fPkvxTyAeq6KD90qFczAh3jOMit JAXIFfrGKex.E0XZkBnrzcdytAtnWRk4iM6WDa2uf3h60t0Z.U9AhUuVGutTHs0feM65L_kVKdDB rlsTvmGsbVmELN8cRv4X3ykKG0UG_PHCWzLeCyDhz7cNG0xbSLzHkKZTzTaMmPMUhnk2llwvHvST qKqMuQgoQ6aN8VbJGbNBfkL9ULWuhwf9aJh1VHZIl1FeRbZzXJImqeknkelplGHB4yfTUqUO9ai8 t6k6nh2TSYDrK7vVPxlWsI4_GxIef0JT1r33yKNxyuc7UIlyjkqZXAH9LHHNHPDRQIlrtKamIUT4 KOG9dyore6PL_j0QOSYs4Muh8JVPuzqoHGGtOU8tNJKX16lLKZ_dbwv1o22sjqBFw8lSXbPV2zDu EjTRofGrLS929PssXaWhq0zJ_LnKEeVcfyCnS996QwhF97CMHxBONXkmjhOVZHo9xcmeagWWjTGz i44vyj4.NT7E1cMhLA9R0jlwp1Sg5cdAUBPpb0S3KMISNxkqQu51S0nYt8VCs4CNlIBv5TqkdnIu MtIT5NHNJVHArmJuJ9Gkn3558SGyeGEhdvrSxLaV9UGT_2ugOGBjBlzyQ65h7BptFOXYhj7vlgx6 bePSgX_kXoK4_OaDA.PhvJQzQE6bPByk2COPhMmJzAa3Bcw5HNCoM8qO7_UXaOsAUAhsqiyYirJe c67rQ8Qp.8KvO_ITq18N4i7gq.2GETVdAJy09ETvkzLnbuBxy.dRngAjoTrzmkAcXekMK9gQ_9hu L7Ktsz8NVm7iFEVL00r5iAmUdgNuUWIHRmCu7y1GRfmT0kBKu3YGMCqBJdnl18G0wiLk18DOVA7X LPXQhyV1LY5xUlkk0_gyZ8J6O1kyZOaUYv1__SGJfn4BjUC6boumQ5cNBrtwdTdkmxLO.n4YPL0J dQycw4vRf3g_uIA.KzEWJLQyWyLZB1dDp1R0Dz3nMxVFa5XLltCBHbmwbXeSVmkqthYxnw_U2vGl BdEOQ3FPpuVmrrmOFlt61ZIsQzJlGUBLbSk40v1Pso63QvOXhEFBUza82rskCoLZb2C2MVGZWpgw 8aphC01MCYQ_CT6gykbB3GbB80NsaJMh1hZDODyxhGeTF9iiTE8Rt1Gt7iN.Www0RWsFfjhR0Xwn NCx8vCz8kA6K2Z.U7uJC.FZuaP.Qlb3wmDhCBQNubTwl.xAP78SRHotSKFN0kpg7Wy8rzg8zsoHl wEjLa6Uwi0ei9gjJyHHltFgMimoo_ziOyUCjvXPHFvpRYOF_dUn7VxrpwsbXyWurmh.w5ebSFpav ZbplzC7.VbL1f9Z.RmxasCr4AoUcu0eOMi43v8UuCT6.qzBH0mZWlZNrOpFs_Jf9HfmHOlA5rcqS CrM_hPpJzzld5RJiBY8b.wdYboidlH_RbC0fdWUO0WSB5PvoJspQv7mGNRl6Q8Kw18nooOjG5w_N PNp3.lgFOzYrYz0DxaNKOt4g0uHNK78HNIlzZ0GepMNphGecQoWzLBODHW6uV8vW901GN4MTjYp_ OPpLm3xp.VTiNJ44s34n9ULWiFAzHI3cHgHUvuWYlraKouMLN6sFN8mkbxQiBMt5iYmJ5E_vsh8u 7BK3vqTisyV6TIagEdBf97y9JBi6I0bF2mODXZjCfSSVjv8tF.kOeh.ry4PgJFl4u.YhBWWD0l.I WstZ.Gdra0vm6iJCVg3Yak1pxAVoPgjOgGqTReTMoXNZvVaMhRkTCq518uIo3afm6x4mJ4swicaf qCTZjwjv1Ora_lHt_9mozdb9PadyRcANap.Lor3dkAeAHLpSHIZMh6kJLPtt6P4FNb5rqppI_fHx TRL7VkRT7mpBPcMdsJsX2bdtR5QO5MKjhPa9nONDt.V1euD0FcrQp9g2hOCg0p6DYaZ6ycVqNHxg y8L5rF6RU9Z.MzWGXU.bKCC5.TU6Ab2bNcVZ62bRwHpCQP.FsQtz2MI5CuRetYjcpLkov81NVgdW iqnwqPGt6.qfVPEj9wYVyrYdRxTUm4LLUtAx6V_z9NFdLu5vkC_QJ1.hYXvYMM1cjbon_j6tMhJU bZ73dIuVAmIHl7JwRE0smUxllTzRjwMTEVFpH38podDobApu8neJtVBg4R24vaAlwuuID7YizLJB Oivq91C5JdxIxAMzaCJlDXlr3Zwhy41Ao4Db3N_SCeRPdX6MlKNPnTk9.prarG8LsD8E8eBA7Jso vGz3Owg-- X-Sonic-MF: X-Sonic-ID: 97965a78-3251-4b95-a397-1b6d27c4d31e Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 17:53:27 +0000 Received: by hermes--production-gq1-869cc4b577-lltcr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ddf7e441c9afd861e22a1d49c5e3b918; Wed, 19 Nov 2025 17:53:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #5] [Common range #0..#10 __je_pa_alloc] Date: Wed, 19 Nov 2025 09:53:13 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> Message-Id: <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.963]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; BLOCKLISTDE_FAIL(0.00)[98.137.69.147:server fail]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4dBTcH2rLhz3R3q On Nov 18, 2025, at 22:10, Mark Millard wrote: > I'm only sending notes from testing of how similar other failures = appear > to the 2 lists. Folks can ask that I do otherwise for them if they = want. >=20 > This one also does not have area_malloc involved at all. >=20 > This one is for size 8192 (2 pages). It looks like #0..#10 are similar = to > the prior reports. #10 is __je_pa_alloc. >=20 > #11 is: arena_slab_alloc >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 > #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 > #3 0x2a196128 in ehooks_debug_zero_check (addr=3Daddr@entry=3D0x2e12b00= 0, size=3Dsize@entry=3D8192) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 > #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080, = new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff9747, commit=3D) > at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 > #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D8192, alignment=3D4096, zero=3Dtrue, commit=3D0xffff97a7,=20 > growing_retained=3D) at jemalloc_extent.c:1003 > #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 > expand_edata=3D0x0, size=3D8192, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 > #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D8192, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 > #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D8192, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 > deferred_work_generated=3D) at jemalloc_pac.c:178 > #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, size=3D8192,= alignment=3D2147483615, zero=3D, guarded=3Dfalse, = frequent_reuse=3Dtrue, deferred_work_generated=3D) > at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 > #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D8192, alignment=3D, slab=3Dtrue, szind=3D35, zero=3D, guarded=3Dfalse,=20= > deferred_work_generated=3D0xffff986f) at jemalloc_pa.c:139 > #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D35, binshard=3D0, bin_info=3D0x2a2200ec = <__je_bin_infos+1680>) at jemalloc_arena.c:839 > #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4618, = cache_bin_info=3D0x2a600506, binind=3D35, nfill=3D10) at = jemalloc_arena.c:1034 > #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4618, binind=3D35,=20 > tcache_success=3D0xffff991f) at jemalloc_tcache.c:238 > #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D35, zero=3Dfalse, slow_path=3Dtrue) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 > #15 arena_malloc (tsdn=3D, arena=3D, = size=3D8192, ind=3D35, zero=3Dfalse, tcache=3D0x2a2e42c8, = slow_path=3Dtrue) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 > #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D, usize=3D, usize@entry=3D8192, alignment=3Dalignment@entry=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8) > at jemalloc_arena.c:1224 > #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, = tsdn@entry=3D0x2a2e42c8, usize=3D8192, alignment=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8, is_internal=3Dfalse, arena=3D0x0) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 > #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D8192, = alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 > #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff9a14, = dopts=3D0xffff99f4, tsd=3D0x2a2e4060, size=3D8192, usize=3D8192, = ind=3D) at jemalloc_jemalloc.c:2398 > #20 imalloc_body (sopts=3D0xffff9a14, dopts=3D0xffff99f4, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 > #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff9a14, = dopts=3D, dopts@entry=3D0xffff99f4) at = jemalloc_jemalloc.c:2693 > #22 0x2a15677c in __aligned_alloc (alignment=3D8, size=3D8192) at = jemalloc_jemalloc.c:2821 > #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D8, __size=3D) > at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 > #24 operator_new_aligned_impl (size=3D, alignment=3D8) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 > #25 operator new (size=3D, alignment=3D) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 > #26 0x20ff35f8 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:92= > #27 StartNewSlab () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:344 > #28 AllocateSlow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:200 > #29 0x26c0ab48 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:176 > #30 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:214 > #31 operator new () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:448 > #32 getMachineMemOperand () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:496 > #33 0x2705c62c in getStore () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.c= pp:9015 > #34 0x270941b4 in visitStore () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBu= ilder.cpp:4746 > #35 0x2708d80c in visit () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/Instruction.def:173 > #36 0x2708c9e4 in visit () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBu= ilder.cpp:1346 > #37 0x270f53c8 in SelectBasicBlock () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:838 > #38 0x270f4b84 in SelectAllBasicBlocks () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:1863 > #39 0x270f1f24 in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:631 > #40 0x28300224 in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp:70 > #41 0x270efd6c in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:374 > #42 0x26c15e88 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:94 > #43 0x276a9e74 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1440 > #44 0x276b0d40 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1486 > #45 0x276aa5e0 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1555 > --Type for more, q to quit, c to continue without paging-- > #46 run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:541 > #47 0x2216d2e8 in RunCodegenPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1157 > #48 EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1180 > #49 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 > #50 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 > #51 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 > #52 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 > #53 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= > #54 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 > #55 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 > #56 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 > #57 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 > #58 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 > #59 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 > #60 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 > #61 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 > #62 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 > #63 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 > #64 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 > #65 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 > #66 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 > #67 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 >=20 >=20 >=20 > 0x2e12afd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 > 0x2e12afe0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 > 0x2e12aff0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 > (gdb) x /1024x ((size_t*)addr)+0 > 0x2e12b000: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2e12b010: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2e12b020: 0x00000000 0x00000000 0x00000000 0x00000000 > . . . > 0x2e12b650: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2e12b660: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2e12b670: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x2e12b680: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2e12b690: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2e12b6a0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > . . . > 0x2e12cfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2e12cfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > 0x2e12cff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a > (gdb) x /1024x ((size_t*)addr)+2048 > 0x2e12d000: Cannot access memory at address 0x2e12d000 >=20 >=20 >=20 > For #0..#10: The prior examples and the above > agree about: >=20 > #5 __je_extent_alloc_wrapper zero=3Dtrue >=20 > But also there was in this example: > #14 tcache_alloc_small zero=3Dfalse >=20 > (The others before #14 are optimized out.) >=20 >=20 > So summarizing some of the failure results so far . . . >=20 > The common part of the call chain is: >=20 > #0 thr_kill () at thr_kill.S:4 > #1 __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 > #2 abort () at /usr/src/lib/libc/stdlib/abort.c:61 > #3 ehooks_debug_zero_check at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 > #4 ehooks_alloc at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 > #5 __je_extent_alloc_wrapper at jemalloc_extent.c:1003 (argument = zero=3Dtrue) > #6 __je_ecache_alloc_grow at jemalloc_extent.c:126 > #7 pac_alloc_real at jemalloc_pac.c:124 > #8 pac_alloc_impl at jemalloc_pac.c:178 > #9 pai_alloc at = /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 > #10 __je_pa_alloc at jemalloc_pa.c:139 > Note: some #11+ can show arguments with a zero=3Dfalse >=20 > All the non-zero Bytes in the pages being checked are 0x5a bytes. > The zero Bytes (if any) come first so far. By no means do I know if the below is the actual problem. The one place I see zero possibly becoming true for __je_extent_alloc_wrapper by the time of the backtrace is via: void * extent_alloc_mmap(void *new_addr, size_t size, size_t alignment, bool = *zero, bool *commit) { assert(alignment =3D=3D ALIGNMENT_CEILING(alignment, PAGE)); void *ret =3D pages_map(new_addr, size, alignment, commit); if (ret =3D=3D NULL) { return NULL; } assert(ret !=3D NULL); if (*commit) { *zero =3D true; } return ret; } (So pages_map behavior vs. commit usage is relevant. See jemalloc/src/pages.c .) extent_alloc_mmap called via: /* * If the caller specifies (!*zero), it is still possible to receive = zeroed * memory, in which case *zero is toggled to true. arena_extent_alloc() = takes * advantage of this to avoid demanding zeroed extents, but taking = advantage of * them if they are returned. */ static void * extent_alloc_core(tsdn_t *tsdn, arena_t *arena, void *new_addr, size_t = size, size_t alignment, bool *zero, bool *commit, dss_prec_t dss_prec) { void *ret; assert(size !=3D 0); assert(alignment !=3D 0); /* "primary" dss. */ if (have_dss && dss_prec =3D=3D dss_prec_primary && (ret =3D extent_alloc_dss(tsdn, arena, new_addr, size, alignment, = zero, commit)) !=3D NULL) { return ret; } /* mmap. */ if ((ret =3D extent_alloc_mmap(new_addr, size, alignment, zero, = commit)) !=3D NULL) { return ret; } /* "secondary" dss. */ if (have_dss && dss_prec =3D=3D dss_prec_secondary && (ret =3D extent_alloc_dss(tsdn, arena, new_addr, size, alignment, = zero, commit)) !=3D NULL) { return ret; } /* All strategies for allocation failed. */ return NULL; } in jemalloc/src/ehooks.c called via: void * ehooks_default_alloc_impl(tsdn_t *tsdn, void *new_addr, size_t size, size_t alignment, bool *zero, bool *commit, unsigned arena_ind) { arena_t *arena =3D arena_get(tsdn, arena_ind, false); /* NULL arena indicates arena_create. */ assert(arena !=3D NULL || alignment =3D=3D HUGEPAGE); dss_prec_t dss =3D (arena =3D=3D NULL) ? dss_prec_disabled : (dss_prec_t)atomic_load_u(&arena->dss_prec, ATOMIC_RELAXED); void *ret =3D extent_alloc_core(tsdn, arena, new_addr, size, = alignment, zero, commit, dss); if (have_madvise_huge && ret) { pages_set_thp_state(ret, size); } return ret; } in jemalloc/src/ehooks.c called via (so is ehooks_debug_zero_check): static inline void * ehooks_alloc(tsdn_t *tsdn, ehooks_t *ehooks, void *new_addr, size_t = size, size_t alignment, bool *zero, bool *commit) { bool orig_zero =3D *zero; void *ret; extent_hooks_t *extent_hooks =3D = ehooks_get_extent_hooks_ptr(ehooks); if (extent_hooks =3D=3D &ehooks_default_extent_hooks) { ret =3D ehooks_default_alloc_impl(tsdn, new_addr, size, alignment, zero, commit, ehooks_ind_get(ehooks)); } else { ehooks_pre_reentrancy(tsdn); ret =3D extent_hooks->alloc(extent_hooks, new_addr, = size, alignment, zero, commit, ehooks_ind_get(ehooks)); ehooks_post_reentrancy(tsdn); } assert(new_addr =3D=3D NULL || ret =3D=3D NULL || new_addr =3D=3D = ret); assert(!orig_zero || *zero); if (*zero && ret !=3D NULL) { ehooks_debug_zero_check(ret, size); } return ret; } called via: edata_t * extent_alloc_wrapper(tsdn_t *tsdn, pac_t *pac, ehooks_t *ehooks, void *new_addr, size_t size, size_t alignment, bool zero, bool = *commit, bool growing_retained) { witness_assert_depth_to_rank(tsdn_witness_tsdp_get(tsdn), WITNESS_RANK_CORE, growing_retained ? 1 : 0); edata_t *edata =3D edata_cache_get(tsdn, pac->edata_cache); if (edata =3D=3D NULL) { return NULL; } size_t palignment =3D ALIGNMENT_CEILING(alignment, PAGE); void *addr =3D ehooks_alloc(tsdn, ehooks, new_addr, size, = palignment, &zero, commit); . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 19:00:41 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 4dBW5l6CNGz6J7Gx for ; Wed, 19 Nov 2025 19:00:43 +0000 (UTC) (envelope-from des@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 4dBW5l5FMCz3d9Z; Wed, 19 Nov 2025 19:00:43 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763578843; h=from:from: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=SxHKZNiLniRC/MKdbEmTohddDRMBy9NlY1Sm9CSIMBw=; b=MQrWGBi8eMY53s2phonuEkkoCNbHaw3O6zwYeKNFmxBiqxrheKuUsRJn4fQsaC18XGTeli mfKeHkZHr7JgwjzDCmrFrLohB09k2sWj2KrTDB21Kid8iobCpdop+A2sT3Ev4NDYdAqi+h N+43zMca+GsehMUQ54sTfHBaHJiSU2EkG8jKLEy550ZYrQsjaWbavt11pm9po1s3Aog0+h uuKHKNtZBNbePcCDSG+6L3RjPIEJGx5Lmz3e+I//+XHf+4Mki9JQj/5G3nSZ6JuMV7l71n 9iG42PErF/nFKdcvMHYeeSE2JY4FNOd1TrzcCCryqkgv55B6wfFtefaaPPrYkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763578843; h=from:from: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=SxHKZNiLniRC/MKdbEmTohddDRMBy9NlY1Sm9CSIMBw=; b=bg1eFvSbshU40A6Wik1PUByFcbE6zI6XvyZkowTD6IqWXPq62P1rkdLFawB9pXghqMrmA1 8E6dhI3HbwEitzKleD+WYMACUVwvTC93ggKDOX4dLJAYwTgLDB+JsjDzRu1ognPO55NzZI ALFpBFivKBUT45KfQ6CwKPmDbblIcDQDxxSe3l6mkgK48FHBype8tVfasFhY5viWBc5Ls9 dL2/tGlhNTmEN2NjMOLG+jHrfjxf7WMdoP0SzdYeg1lwHFn/A9SGD2/lHP5sLBTouHIctc cAPYUJP7dEb1QyY2dAU/f9IuHzajDPkiud/8tYTULw3JvGqjfnP6QCpZHxRLpQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763578843; a=rsa-sha256; cv=none; b=eFCw0KwVTUitIyN9UiDYQ1kD4+G924aXZE6iuOWBa5BKiXIcCM2M65wewYSiLjh3T71vbp rH9/FKC5L1p/sfoiPgwdTnF7Mvjc5u/tX7dA9VPMzQb/D34H4KCLXg6Zjer2ZQsPdTCUQH rc2vEXy/jh52Y04iwA2UshErrjFbjYQ72okR5H0xAlusHioZKBylXYoWdtHtrM0Sn3Y9K3 UY74WsE57Qnjhy+Jv7rGhqa9FDHJ2Lp6YjhBxR7i3VQuNN8CuqNRFlIvn2uauo5ILdFSYn c51vxMOd7ZM8gXi+V+Jcn+uF9KoppX7lRWhSbOFoZopKSFVwvQuJr5aBJAIqIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (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 did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dBW5l3prFzJvW; Wed, 19 Nov 2025 19:00:43 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 61649A5DF7; Wed, 19 Nov 2025 20:00:41 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Gmelin Cc: void , freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase In-Reply-To: <20251119172520.4af73dd0.grembo@freebsd.org> (Michael Gmelin's message of "Wed, 19 Nov 2025 17:25:20 +0100") References: <20251119172520.4af73dd0.grembo@freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 19 Nov 2025 20:00:41 +0100 Message-ID: <86y0o1x2xy.fsf@ltc.des.dev> 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=utf-8 Content-Transfer-Encoding: quoted-printable Michael Gmelin writes: > What is the procedure to run a custom kernel with pkgbase? In the > last couple of years we needed stability patches (pf, zfs, etc.) on > almost every second release (at least temporarily, until an errata was > created). > > Would we need to run our own pkgbase server in this case or is there > another (non-hacky) way? You can check out a source tree and build and install a kernel just as you've always done. You'll just need to explicitly set DESTDIR=3D/ when installing to override the pkgbase check. You can also set up poudriere to build your own pkgbase set. It's really easy, especially if you have a git repository with your patches already applied. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Wed Nov 19 19:18:44 2025 X-Original-To: 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 4dBWVh6NXZz6J8Jb for ; Wed, 19 Nov 2025 19:18:52 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBWVg5xZDz3gcJ for ; Wed, 19 Nov 2025 19:18:51 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=kcIghjRc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ianfreislich@gmail.com designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=ianfreislich@gmail.com Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-786a85a68c6so675627b3.3 for ; Wed, 19 Nov 2025 11:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763579926; x=1764184726; darn=freebsd.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=xCRiCtef2/5gbQh1YSjQ42sYYfAJZ0GMnFCiigXNssM=; b=kcIghjRcBs1ZsJkJ4t6xTU2GaxOoN2rA+bJCWm2enQ9SkPqnjX8IcQ/LfeyHLrY6hY /EintHuSGFFoCYLSacCEyfw/+yMTOjjksQufrGfpqURQWafki9ierGt45QMT1poBYysn ZRuOWd1U/zaXDx4H0t5tAOPVcZPqszP6ThBG05JuqUtZUgrMeP8Snu4nbzFt3CmRbLVV 6fzcEHDTh952UKOcCE3/WQhOGWz0NDtMqyfgaPQ6qqoqur7zkEpvVA1RuqIa0dI2PyQW AfaePgPsHiGswPgsp7iN8EvvvrVzHAXNqr5KeLwbw/wBc+NbsXx0YOwsbl5kDi7fDNKI Wvhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763579926; x=1764184726; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=xCRiCtef2/5gbQh1YSjQ42sYYfAJZ0GMnFCiigXNssM=; b=SAY93ETUZPjPoXm3VDPfECTM8T5+4FkFalCafrg8bBYBSuJ0vIQkjYCBUzaAhkbMmy AGfqRMoB8E9poSvHCABeaefUFezgJOs3tx8lzRE3nhCOE4C9b1jsO//N1yMZwOiRGKK2 C/c20qBM0e3pjz+794tDqN0RZXplpVwxXNqxB4LcFFgRKYuWkMVNyRUm9K30UYVzV0MD 7PwuTX9vKm8THSN2MZnOAUyeEUYg2CmOy9cGNOhfpHDgTZOStGay8PtTM46L2C5IgKBS FRR4ky2mJQKv8993Qt+Gq2WZbrTrobFvOoZOTPXue9a3iS7vdxXDnBMQHPXtgD5RQ3aW FOug== X-Gm-Message-State: AOJu0YwgjGeHEREIIilABXUGP0qJ3RT7Mb6oe7LdlIkmoT+ZzR0u+N8u XNfBLooyLtqbAOrKzIjD2NZDVnxlTc+VbZK2gNJxh3YJGzVKDVE8rsdv4DzLIrqN X-Gm-Gg: ASbGncspjxWYGu98YDi3LSbcvP2v42HPzbPRjzZmBNJdyzEVrsK3fKMDrz3EvHiRrsG W3M8gYcfhFcGbNFzSMDgkuWC64IU2i4FHU7w3IjetmTWUH6sXiKwAfNxTeJ6MWtNiveVFBCBKv/ RZna/yn0BI3Uxg128irr++sq7OvMImF8xsVF32tbnvyTqACXys5dw66xtMV+wgFChBX1vXfdjb+ Ifu6GEzd8j3u+Oh2VAx74Qzc++98lY9/Lv8hHBbH0+UaCSPW6D+zZu2M2lnV9zZydiuR3aROMAz vRMDpeqxFYtHKYFpKcvPN6rg0wuH1MpX1ozBUnHKt3dx6X/xGgE2wscuynMl9PVkSsypOxInb7M CeVzFGSMpEtGcnsmBshFBPsb5iwOF74DtoioJ6BlFZmYOBR/9XlgYFBQQids2neLyoOM+I/hI+/ q1VXiRZ7YplKubRIBHlcKzs4svQtL2dls/u2CE9xfk3Wxfe6akxV+/JItkGa0b2njxdA== X-Google-Smtp-Source: AGHT+IGCYGbWTpfQ46tPF2eJldKek5C04xcSNgIaDTiNsFLiAi24ItqQEqHQulonqyiDPSEnCA0Krw== X-Received: by 2002:a05:690c:4485:b0:786:9774:a39f with SMTP id 00721157ae682-78a7955d80fmr4843147b3.5.1763579925736; Wed, 19 Nov 2025 11:18:45 -0800 (PST) Received: from ?IPV6:2600:1700:18f0:6812:129a:8666:ef01:3293? ([2600:1700:18f0:6812:129a:8666:ef01:3293]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78a7992511esm917157b3.35.2025.11.19.11.18.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Nov 2025 11:18:45 -0800 (PST) Message-ID: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> Date: Wed, 19 Nov 2025 14:18:44 -0500 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: Thunderbird Daily Content-Language: en-US To: FreeBSD Current From: Ian FREISLICH Subject: nvme.c:2012:2: error: call to undeclared function 'memmove' Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.74 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; NEURAL_HAM_SHORT(-0.76)[-0.756]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from] X-Rspamd-Queue-Id: 4dBWVg5xZDz3gcJ My kernel build started failing recently with the following error. I use a custom kernel config but looking at NOTES, it's not clear that I've missed an option that would make it compile. In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared function 'memmove'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); | ^ 1 error generated. *** Error code 1 I've also tried compiling after blowing away usr/obj. Ian From nobody Wed Nov 19 19:24:17 2025 X-Original-To: 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 4dBWd65NF6z6J8Yf for ; Wed, 19 Nov 2025 19:24:26 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBWd62xQrz3jkc for ; Wed, 19 Nov 2025 19:24:26 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1763580263; x=1763839463; bh=Np+rPQB+bXeiNbIvl3JIwe23cZlnZn28fXfewB+Eyuo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Qj66ff0Oy+yTqR/jX/qhFAPjSbaCcoZ6ePv36QqvGScy/zd4lSDMkYAKHDdfWH96l /tzJV20oAZ5ZweOfT4lPE8q/84H73gPiQ+gxxJI5msdtPthxiO7TGEcXZ5cGT2cHp7 mVttPsOaOBsaka5IjHAgvc7X29QRD0QnpwkHXgpO+auZ5QSQPxT2rwHLeAhWkOUDMR m5s7YTUUSWTzb+ZzSYjDEn3lXg8PxmLY+9booYt6692cInn1xqKAST1cmyTHID7a+9 Xe6NWBhoMZRx5au+dmDuly3hitXa15y0Zf9YSUdoTthdXuRtZKG0o2fZCrP7CPH5pb Hl2DQ8M5KzYdA== Date: Wed, 19 Nov 2025 19:24:17 +0000 To: Ian FREISLICH From: Minsoo Choo Cc: FreeBSD Current Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' Message-ID: In-Reply-To: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 1a776d18bbead6ad4dc21bc7e4a302f9bc026f2d 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBWd62xQrz3jkc On Wednesday, November 19th, 2025 at 2:19 PM, Ian FREISLICH wrote: > My kernel build started failing recently with the following error. I use > a custom kernel config but looking at NOTES, it's not clear that I've > missed an option that would make it compile. >=20 > In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: > /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared function > 'memmove'; ISO C99 and later do not support implicit function > declarations [-Werror,-Wimplicit-function-declaration] > 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); >=20 > | ^ > 1 error generated. > *** Error code 1 >=20 > I've also tried compiling after blowing away usr/obj. >=20 > Ian memmove is declared in systm.h, but I don't see include statement for systm= .h in nvme.h. Could you try including in sys/dev/nvme/nvme.h = and build again? From nobody Wed Nov 19 19:50:41 2025 X-Original-To: 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 4dBXCY4PXZz6JBGF for ; Wed, 19 Nov 2025 19:50:49 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBXCY2S8jz3mHZ for ; Wed, 19 Nov 2025 19:50:49 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-7866bca6765so1004267b3.1 for ; Wed, 19 Nov 2025 11:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763581843; x=1764186643; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=M4djE3rrJui9u330enHFyWMp9twuvW1bNKokGZcxZvc=; b=TUHJXft/XhwYooYiCP49UaMyyqdVHhSN7P+vq/dFYHq2M5tB8aJfnlCDsLuJMDhqOm 9InHXpHMfH6lpIhC1P8QATgc5fIQESywix6VI+sF4NRROVOsWT37PbnXExTMKtCyHO7I i/Y0baAAprofLbGDcdhkK+ac/Nir9E9a/tiLd/DERAEMxX59vnaTLxSdEljvteKZpv+n 6+buXTn7nF+u5U+h1ayGLgYISXyUp41vUi2QS1Pfp1fSmEKIFy9b2TdV5X06Te7L0xdQ 9XFqmhcS+QwS4IPfTKMafHwQjGZM51+D/a5MCUuQcDySeC9hE4ekw68lXvRc1P/hJRII cibA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763581843; x=1764186643; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=M4djE3rrJui9u330enHFyWMp9twuvW1bNKokGZcxZvc=; b=I4+vufqaTTHEA2DZpgAhDt5X3uR9OdRpQfRwUlt6arrYquldVFzIG+2f/n1jnzGohF 3y4/k3MFFhzsaZvgnAKrUt3oS21joC0dnrr/wA49l7rbeFD+9sdVfMlrRscpBZKLU008 4eXFbOPIaTeZd0X3BZRc29jbx4noHxSWULc5ogr/IKR++jk77Gp4bqmEBXgGinTVf8xV VWrfVKxEGDvsPH1tL0KqFAAK/XFIyHLJKBd0RLOtn6OEii/008n11IIsrsJREbc80AoB 6g4YjEYuQ9xz2CVrFUJJTvmrfx218EluwsEDrJNpBoF5GmHijbnLaovmULLDG02JhlZA 9DuA== X-Gm-Message-State: AOJu0YzNTmVV1L3ago49ETM7FRfxJGc1uuymLDqqbqmAGGopw7Cbdj2W kF1r9zxpV2sOuIJDKWc+qvtbgUIZX+0y5nf9PDvsjzf9tN8E/mSs9Ju8ecCmLzAq X-Gm-Gg: ASbGncuNte/jl0+S8dOK7ZPSXADE4Zt55Y4PlIUjZPPYdypZP/WCDDxqwtkmEscJS2u KHrBZXJExaTkUIzIgG2TLSpbgjmJVPKTRUHyWLfa+pPFT0JlbwZcDl+uNH6cVYbL7yHjDm/7K19 3LWe0hiZMxNclAlYLRIY1PLm5ySLvO3qHJwYkMRRKomx/aAm19JKo/WclpAp23WDpKqw0Px0OLk G2QVnr++1rWRKb2Lu3CvkWKW8sVttNZIhMvrJBdjB19DbD7u8Ah4RaXt+a/QoBEqTO9e3E+U2Jz kIuf9/mYR3dAlHSJJxm5qc7/i4/W7ZUdOlYqvSgD7APf82sHDc9wWvfh6uSII7tnLZoGI0Xx6gc eO+Cbwx5oO68Nj8cYQq6vTgp/uGG4xKnImCEuDhTq26IxAH5rwkN5WVCqek+sY0xF2TaU2JW5nj ClDR1EaBipPeXl8txlxjN3+CIffeWbUf1ZYjHh2G8aBP1GLKCFXF8h479dV8jDJPJ4Zjn3TkaVu lpg X-Google-Smtp-Source: AGHT+IGGMlbmeFNF58QcS2u3K9i6YHAQQA8maau2cVF0Hz6gGRYOQC6Ie0aQ1vqEcicAXEXmQXPVmA== X-Received: by 2002:a05:690e:d03:b0:641:f5bc:695a with SMTP id 956f58d0204a3-642f7ddd767mr210308d50.70.1763581843069; Wed, 19 Nov 2025 11:50:43 -0800 (PST) Received: from ?IPV6:2600:1700:18f0:6812:129a:8666:ef01:3293? ([2600:1700:18f0:6812:129a:8666:ef01:3293]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-642f71ae74fsm142844d50.22.2025.11.19.11.50.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Nov 2025 11:50:42 -0800 (PST) Message-ID: <60449f55-58e7-4f8b-aa0e-3f288dab5146@gmail.com> Date: Wed, 19 Nov 2025 14:50:41 -0500 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: Thunderbird Daily Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' To: Minsoo Choo Cc: FreeBSD Current References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> Content-Language: en-US From: Ian FREISLICH In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBXCY2S8jz3mHZ On 11/19/25 14:24, Minsoo Choo wrote: > On Wednesday, November 19th, 2025 at 2:19 PM, Ian FREISLICH wrote: > >> My kernel build started failing recently with the following error. I use >> a custom kernel config but looking at NOTES, it's not clear that I've >> missed an option that would make it compile. >> >> In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: >> /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared function >> 'memmove'; ISO C99 and later do not support implicit function >> declarations [-Werror,-Wimplicit-function-declaration] >> 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); >> >> | ^ >> 1 error generated. >> *** Error code 1 >> >> I've also tried compiling after blowing away usr/obj. >> >> Ian > > memmove is declared in systm.h, but I don't see include statement for systm.h in nvme.h. Could you try including in sys/dev/nvme/nvme.h and build again? It builds with that, but coincidentally GENERIC builds without that change. Ian From nobody Wed Nov 19 20:42:41 2025 X-Original-To: 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 4dBYMW4N2mz6JFW5 for ; Wed, 19 Nov 2025 20:42:47 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-24427.protonmail.ch (mail-24427.protonmail.ch [109.224.244.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 (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBYMW22pmz3xM4 for ; Wed, 19 Nov 2025 20:42:47 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1763584965; x=1763844165; bh=3cTV0W52d+GKn9HZgnzQkRH9eSo58vB3RxixkAlmoNs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fjdIdQccKCapQs4MQrV5SNOSG1Zfxmxvo1FDHScztGtPR4dkhpOrwH9jKGkceG9vS sgYhEzC2W0iSg3CfkdcYBolNyiFxLEj4Ez/DKotbWBj2rMJameU7P2RIuE+lQA7WQf lzYXoKCOCL3B8HAGk6g/Y/S5M0i+i2+ZBHqgPtL78+hnc+dlZReRDN7BXdHnC11MP0 jQcbs5kz8Tey3SAgaYfeMZWj6v3k6dZSUNhqoq+yucHhjPg2lKyJ3yGNh//m9dfjh3 YSI5fF1+JwXw23Rfxc3FLczTTmj9mRRyImTfKSqGdQKr3wq1XvfuLP3k9ypid04b6z scoAdZW57yQrA== Date: Wed, 19 Nov 2025 20:42:41 +0000 To: Ian FREISLICH From: Minsoo Choo Cc: FreeBSD Current Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' Message-ID: In-Reply-To: <60449f55-58e7-4f8b-aa0e-3f288dab5146@gmail.com> References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> <60449f55-58e7-4f8b-aa0e-3f288dab5146@gmail.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 06a6a2254dd3654147f0f8196a97050866887504 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:109.224.244.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBYMW22pmz3xM4 On Wednesday, November 19th, 2025 at 2:51 PM, Ian FREISLICH wrote: > On 11/19/25 14:24, Minsoo Choo wrote: >=20 > > On Wednesday, November 19th, 2025 at 2:19 PM, Ian FREISLICH ianfreislic= h@gmail.com wrote: > >=20 > > > My kernel build started failing recently with the following error. I = use > > > a custom kernel config but looking at NOTES, it's not clear that I've > > > missed an option that would make it compile. > > >=20 > > > In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: > > > /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared functi= on > > > 'memmove'; ISO C99 and later do not support implicit function > > > declarations [-Werror,-Wimplicit-function-declaration] > > > 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); > > >=20 > > > | ^ > > > 1 error generated. > > > *** Error code 1 > > >=20 > > > I've also tried compiling after blowing away usr/obj. > > >=20 > > > Ian > >=20 > > memmove is declared in systm.h, but I don't see include statement for s= ystm.h in nvme.h. Could you try including in sys/dev/nvme/nvm= e.h and build again? >=20 >=20 > It builds with that, but coincidentally GENERIC builds without that chang= e. >=20 > Ian Could you send your kernel config? Maybe sys/systm.h is included under GENE= RIC but not under some configs. From nobody Wed Nov 19 21:04:25 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 4dBYrs4fKLz6JGc0 for ; Wed, 19 Nov 2025 21:04:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4dBYrq6z67z42Hv for ; Wed, 19 Nov 2025 21:04:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=iY3EFkPY; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763586280; bh=LnbrHx6rTLm4lF99HxhuyPGr0NfL1OMKFm0Xzq7m77o=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=iY3EFkPY3AUWkIdmqYy0Az+gbPD9H+MJrOgpMKUToUG+cS2UJx2cZ5feZfDtM8ACBCvGAry2ttU82z6HnPSqjb5H1oS6e4u7caqOkLWuRF2xwHzEi0EYlvBu9Mw8fMTNyB2UTK6LeRNG7NkqzxapOMlTwiWVIECYkyQETIkUwF0f43IqBZUHPUJQeWpdiybteLFK1l6BtknWZyk8dRd/ArBEsUj8FGLqB8QBtUJArqBxC85mthXO+53KFKwgxgUyoWRA09T+KHxRyHJjRLesFpDdMxTbuDm1dKi+taVvOj5tewfifihTt6Cv1vnztIcF1jTwE4s94IMu4Vn6Z7/ZDA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763586280; bh=3CnxOU7VNar9KUE9+AuxpY1XYsCqRBvT8YxXqDcyY1m=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OYBZdTEM9zJEPco0srD/s65eO+BxBcQda1r4eLVr5ui+VOxKfzyfdHdNhvqXeh09k75gQF/58XndxMG0gTaCn9+S+U+vBrbmhD75P0bEkaNLxQkkyLUDb5bp6IbQ9KRjxcUDCS8EbOAPLEWvefxf/YdVthakYh4QONHsMtcHBV96By+pZ8O6Ilaz6aC4STmwzNJHqp1yp2/b4QLPXPLTB55+6ovVVQTZxEkK1iTbe69RDcrJ0ULbdwEQn/+TL2AuzdOZbO/pH3juhebyQ4xFb25eHRi1bXYJibEPD9HOm/9dSc0M28TBz0NHxPfNrqLcGHJK5Wfz8LO7mxP1dQdqJA== X-YMail-OSG: C8Vov.gVM1np8n0IbPksVpPG.9ZNpNxUD.S3N4Rv3wNzxOoAES3YSHGuAGr9FKE h77kx.mb8VqwhtqLrg886VUDxvArUqj9AVZsuP_zlCTiK56H0xcEIgZJJaSY.KHvOPmfl.eMURy0 tXO2SSOum0Ti5lbn0CL4ZfnvoK18Sg4aqFTMaPxLRt4ys_ikGqlsuSxKT_1teAd2boi8YsEJ1tIq 9fUX6ScSN_1nKAJ23M8ipuRhxxUcK62kndYhcZTsYDpLiFzDeSEzbxSYeRGF5FAnsLLQj6CzISY2 qu0ySGER7l9JaoH.YTlDdqR3tm01g0l09C2oL7gl6xsqkCcqnFZscEzOVvNZfdt1a8y90kBVCEdO pKNWWTxcWGDdAzBlHsC2T2PymvHX_9La9UBud009GVyVlO1wM9OwOfrM4mRjFThiE5bqblze1WZx _7hvAzXF9h.RcRRwP2XEk_oHP9QScaxugUR8RG_fCohYkl.43Yg1_EIpcTWnD1rY4SzfVhqwMrdF FUkdGQIFnvZQpcve3.AOhnC09wETphBj0b5vuogVZPZ0XRHNvgc.MBB9n9SJ_5CHTr3cE7RubjrI TEYl2.MZNFxd22iIsggMah8BYw7FaxQXUWIwcgClTBRT8fv642czNSziEi8Onl0uB3fhjmhjAfhl jZtqokHWrpvIVQ1MRIcnU9k0CT5Ry3e9J9JTceQXsxVSL0BLchSDXY1qEP345h.qQ4BTDCHm65Vk wGC9AiUu75FDx9aWnA84SnCatHWj.gKaNAv19VaCaW79QvjB_VI9BWOPElR.T4UgEDzQehBiY4uV IQ1.2E0g2RG1GdDuDy3GSCJcsQVLcHxPT4znyMjAkWoIbjRA.nwWlXGr8ua6mYs4J8dNSuw0fSJE yUzEMChQAFMC0YVQNWEzx64Vi99c8uEbNrnlOHUTeOZH6MhsMekO.YvubsVzE3jOSV_65jcFnFlU 3QxTqNXXAwP1lnF2QF2cO7YtELEhGM5dRzcadaeqC6ch5mcHw8y87LZj.xVTru6s_6XsUxZU2nUw rpz_.XZVIw0eHBV7XxXxCr2nQfsxKkEYtKli4TdK6GKgiT77TO.V360ZmYCMMgGzjsVYXq4jcFw4 v8kVUg_PJnPaL1mWQW.q.HflQqbrlxe2VDDMwnerzXCR86Ma3a5fp_wMS7iX7Gvt8gIBLjHOyLmS V9RapHwwJnKZ7cVMHwxIp9Ry3.d24y2Dv32HYg8HXgkhI_YXuYVn1bzibr7CwTHNMIAiMZgL9ktZ YsEnVydzfoBLBJFoi6vYbYT1q0flI6E2sBskpRjVSyhCRYjKAxHFr3vbGEwNKwgcIbH9qwjreFGH kCnWOoz9aWpar0w8ln6FoExLP2vw8qiGqlAR0DPjNrloIj2O7BkwxAEvvfs1cua6MNhQTHUZtKn8 pu3zV.dU3b.mYXh36OY8iUyauIfwZd.q7HdhlGRkakHs9pcLpR94ZdixFhNAe65P7Pk0fdR80dgW U4IlnH8TkkCR_ZaUHfxFZALB61NV6gvAISmPzycLQVcbbvHP11kPaiUYMtKbVrBoSK_hGjxPvgx6 LrBvEooz6hDucwrCUxrluHMEmuf.lMa4lpIXNl27kX6_gueUmERV0rRiavj_JNaD2pGUMzEkCzfT u8xGcQVobR9paliMHemPo.0bYi7cIohW00AqpYvFSsALVPB.KxGAOFi_8quynDpYbVX9kk36zSQe VrhNczUMdpd9ScyTblSGQuIXcg5rR8DzeaIEqkoiM4wgC.Zbxxe5eV0_mweLcWeTfI1BubC_x0yC js.xeqHFjmZuv18uwT.CVNpotvZmkOCzvOvCBEpTG5k0AaXG1lQ2b87IBPctImvd0OHUaZHMT3PP LnwQjmctVsIVUscRBRx5fKP2_7R.KgmY7M5Rf.O9stvqe3YKFYk6ynPBsphT4diWeZP1u8OKvvKq MwmdCQUc7TyOh.Xaj5Fb2My6eQMwrwaubMu_4llL90lfP4YDEeGkNjX6JuVJ6EvcKYaP2ACEJWWy 8ren_KFjoW42h6akNT5BAduwNPJUmGgwN7nXP.0.JA6HZGYhp6vUrDc1OOSnJ42vtDBjL1e6qU1x j1VnrFRHOWD84iD_p2di7FGDFtBJPNi6exJdHvnNlzUQjehUEOXtET94phyZIWh.MlW_5hF2qLm0 Buo37VIBsH_qfeLPDkeii6mdxWfZG.88BxVtxe5I5oXU36LiWC20bJeIdgkHklf2yVq1ZewfAuLN Zwkili50wtXbsHOyKkwXmLXnMloteCJSDMQ67oxCNhcz.tluXlIsmIeCMPNSp0MD.PliWcv44zF_ su4X0Hk6.oA-- X-Sonic-MF: X-Sonic-ID: eadc9265-f82c-4b28-9d1c-453bd01dd69a Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Nov 2025 21:04:40 +0000 Received: by hermes--production-gq1-869cc4b577-s7np4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4dcd400842e69cda3e9fbb04a4b42921; Wed, 19 Nov 2025 21:04:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 [Notes from another example core dump: #5] [Common range #0..#10 __je_pa_alloc] Date: Wed, 19 Nov 2025 13:04:25 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.933]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from] X-Rspamd-Queue-Id: 4dBYrq6z67z42Hv On Nov 19, 2025, at 09:53, Mark Millard wrote: >=20 > On Nov 18, 2025, at 22:10, Mark Millard wrote: >=20 >> I'm only sending notes from testing of how similar other failures = appear >> to the 2 lists. Folks can ask that I do otherwise for them if they = want. >>=20 >> This one also does not have area_malloc involved at all. >>=20 >> This one is for size 8192 (2 pages). It looks like #0..#10 are = similar to >> the prior reports. #10 is __je_pa_alloc. >>=20 >> #11 is: arena_slab_alloc >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x2a08ef24 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 >> #2 0x2a145f38 in abort () at /usr/src/lib/libc/stdlib/abort.c:61 >> #3 0x2a196128 in ehooks_debug_zero_check = (addr=3Daddr@entry=3D0x2e12b000, size=3Dsize@entry=3D8192) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 >> #4 0x2a191f60 in ehooks_alloc (tsdn=3D0x2a2e4060, ehooks=3D0x2a600080,= new_addr=3D0x0, size=3D, alignment=3D4096, = zero=3D0xffff9747, commit=3D) >> at /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 >> #5 __je_extent_alloc_wrapper (tsdn=3Dtsdn@entry=3D0x2a2e4060, = pac=3D0x2a601810, ehooks=3D, new_addr=3D, = size=3D8192, alignment=3D4096, zero=3Dtrue, commit=3D0xffff97a7,=20 >> growing_retained=3D) at jemalloc_extent.c:1003 >> #6 0x2a1916e0 in __je_ecache_alloc_grow (tsdn=3D, = tsdn@entry=3D0x2a2e4060, pac=3Dpac@entry=3D0x2a601810, = ehooks=3Dehooks@entry=3D0x2a600080, ecache=3D, = ecache@entry=3D0x2a603dd0,=20 >> expand_edata=3D0x0, size=3D8192, alignment=3D4096, zero=3D, guarded=3D) at jemalloc_extent.c:126 >> #7 0x2a1c9680 in pac_alloc_real (tsdn=3D0x2a2e4060, pac=3D0x2a601810, = ehooks=3D0x2a600080, size=3D8192, alignment=3D4096, zero=3D, guarded=3Dfalse) at jemalloc_pac.c:124 >> #8 pac_alloc_impl (tsdn=3Dtsdn@entry=3D0x2a2e4060, self=3D0x2a601810, = size=3Dsize@entry=3D8192, alignment=3D4096, zero=3D, = guarded=3Dfalse, frequent_reuse=3D,=20 >> deferred_work_generated=3D) at jemalloc_pac.c:178 >> #9 0x2a1c7ae8 in pai_alloc (tsdn=3D0x2a2e4060, self=3D0x0, = size=3D8192, alignment=3D2147483615, zero=3D, = guarded=3Dfalse, frequent_reuse=3Dtrue, = deferred_work_generated=3D) >> at /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 >> #10 __je_pa_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = shard=3Dshard@entry=3D0x2a601800, size=3D8192, alignment=3D, slab=3Dtrue, szind=3D35, zero=3D, guarded=3Dfalse,=20= >> deferred_work_generated=3D0xffff986f) at jemalloc_pa.c:139 >> #11 0x2a16b9f8 in arena_slab_alloc (tsdn=3Dtsdn@entry=3D0x2a2e4060, = arena=3D0x2a600540, binind=3D35, binshard=3D0, bin_info=3D0x2a2200ec = <__je_bin_infos+1680>) at jemalloc_arena.c:839 >> #12 0x2a16ac98 in __je_arena_cache_bin_fill_small (tsdn=3D0x2a2e4060, = arena=3D0x2a600540, cache_bin=3Dcache_bin@entry=3D0x2a2e4618, = cache_bin_info=3D0x2a600506, binind=3D35, nfill=3D10) at = jemalloc_arena.c:1034 >> #13 0x2a1b5694 in __je_tcache_alloc_small_hard (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D0x0, arena@entry=3D0x2a600540, = tcache=3Dtcache@entry=3D0x2a2e42c8, = cache_bin=3Dcache_bin@entry=3D0x2a2e4618, binind=3D35,=20 >> tcache_success=3D0xffff991f) at jemalloc_tcache.c:238 >> #14 0x2a16cef4 in tcache_alloc_small (tsd=3D, = arena=3D0x2a600540, tcache=3D0x2a2e42c8, size=3D, = binind=3D35, zero=3Dfalse, slow_path=3Dtrue) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:68 >> #15 arena_malloc (tsdn=3D, arena=3D, = size=3D8192, ind=3D35, zero=3Dfalse, tcache=3D0x2a2e42c8, = slow_path=3Dtrue) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:151 >> #16 0x2a16cb88 in __je_arena_palloc (tsdn=3D0x0, = tsdn@entry=3D0x2a2e4060, arena=3D, usize=3D, usize@entry=3D8192, alignment=3Dalignment@entry=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8) >> at jemalloc_arena.c:1224 >> #17 0x2a16559c in ipallocztm (tsdn=3D0x2a2e4060, = tsdn@entry=3D0x2a2e42c8, usize=3D8192, alignment=3D8, zero=3Dfalse, = tcache=3D0x2a2e42c8, is_internal=3Dfalse, arena=3D0x0) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:80 >> #18 ipalloct (tsdn=3D0x0, tsdn@entry=3D0x2a2e4060, usize=3D8192, = alignment=3D8, zero=3Dfalse, tcache=3D0x2a2e42c8, arena=3D0x0) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:91 >> #19 0x2a1651f4 in imalloc_no_sample (sopts=3D0xffff9a14, = dopts=3D0xffff99f4, tsd=3D0x2a2e4060, size=3D8192, usize=3D8192, = ind=3D) at jemalloc_jemalloc.c:2398 >> #20 imalloc_body (sopts=3D0xffff9a14, dopts=3D0xffff99f4, = tsd=3D0x2a2e4060) at jemalloc_jemalloc.c:2577 >> #21 0x2a156188 in imalloc (sopts=3Dsopts@entry=3D0xffff9a14, = dopts=3D, dopts@entry=3D0xffff99f4) at = jemalloc_jemalloc.c:2693 >> #22 0x2a15677c in __aligned_alloc (alignment=3D8, size=3D8192) at = jemalloc_jemalloc.c:2821 >> #23 0x29e61a00 in = std::__1::__libcpp_aligned_alloc[abi:se190107](unsigned int, unsigned = int) (__alignment=3D8, __size=3D) >> at = /usr/src/contrib/llvm-project/libcxx/include/__memory/aligned_alloc.h:43 >> #24 operator_new_aligned_impl (size=3D, alignment=3D8) = at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:129 >> #25 operator new (size=3D, alignment=3D) at /usr/src/contrib/llvm-project/libcxx/src/new.cpp:141 >> #26 0x20ff35f8 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase.h:92= >> #27 StartNewSlab () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:344 >> #28 AllocateSlow () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:200 >> #29 0x26c0ab48 in Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:176 >> #30 Allocate () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:214 >> #31 operator new () at = /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:448 >> #32 getMachineMemOperand () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:496 >> #33 0x2705c62c in getStore () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.c= pp:9015 >> #34 0x270941b4 in visitStore () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBu= ilder.cpp:4746 >> #35 0x2708d80c in visit () at = /usr/src/contrib/llvm-project/llvm/include/llvm/IR/Instruction.def:173 >> #36 0x2708c9e4 in visit () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBu= ilder.cpp:1346 >> #37 0x270f53c8 in SelectBasicBlock () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:838 >> #38 0x270f4b84 in SelectAllBasicBlocks () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:1863 >> #39 0x270f1f24 in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:631 >> #40 0x28300224 in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp:70 >> #41 0x270efd6c in runOnMachineFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGIS= el.cpp:374 >> #42 0x26c15e88 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:94 >> #43 0x276a9e74 in runOnFunction () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1440 >> #44 0x276b0d40 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1486 >> #45 0x276aa5e0 in runOnModule () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1555 >> --Type for more, q to quit, c to continue without paging-- >> #46 run () at = /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:541 >> #47 0x2216d2e8 in RunCodegenPipeline () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1157 >> #48 EmitAssembly () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1180 >> #49 EmitBackendOutput () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1341 >> #50 0x225cbca0 in HandleTranslationUnit () at = /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:354 >> #51 0x22cff8e4 in ParseAST () at = /usr/src/contrib/llvm-project/clang/lib/Parse/ParseAST.cpp:184 >> #52 0x22b5a7b8 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078 >> #53 0x22adb800 in ExecuteAction () at = /usr/src/contrib/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1061= >> #54 0x22bf6a90 in ExecuteCompilerInvocation () at = /usr/src/contrib/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvoca= tion.cpp:280 >> #55 0x0002afc8 in cc1_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/cc1_main.cpp:284 >> #56 0x00038548 in ExecuteCC1Tool () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:215 >> #57 0x227877ec in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 >> #58 operator() () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 >> #59 callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>(void) () = at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 45 >> #60 0x27d88624 in operator() () at = /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:= 68 >> #61 RunSafely () at = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:42= 6 >> #62 0x22786e90 in Execute () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440 >> #63 0x22748074 in ExecuteCommand () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:199 >> #64 0x227483d0 in ExecuteJobs () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Compilation.cpp:253 >> #65 0x22765bb8 in ExecuteCompilation () at = /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:1943 >> #66 0x00037ba4 in clang_main () at = /usr/src/contrib/llvm-project/clang/tools/driver/driver.cpp:391 >> #67 0x000363a8 in main () at = /usr/src/usr.bin/clang/clang/clang-driver.cpp:17 >>=20 >>=20 >>=20 >> 0x2e12afd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 >> 0x2e12afe0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 >> 0x2e12aff0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 >> (gdb) x /1024x ((size_t*)addr)+0 >> 0x2e12b000: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x2e12b010: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x2e12b020: 0x00000000 0x00000000 0x00000000 0x00000000 >> . . . >> 0x2e12b650: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x2e12b660: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x2e12b670: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x2e12b680: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2e12b690: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2e12b6a0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> . . . >> 0x2e12cfd0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2e12cfe0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> 0x2e12cff0: 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a 0x5a5a5a5a >> (gdb) x /1024x ((size_t*)addr)+2048 >> 0x2e12d000: Cannot access memory at address 0x2e12d000 >>=20 >>=20 >>=20 >> For #0..#10: The prior examples and the above >> agree about: >>=20 >> #5 __je_extent_alloc_wrapper zero=3Dtrue >>=20 >> But also there was in this example: >> #14 tcache_alloc_small zero=3Dfalse >>=20 >> (The others before #14 are optimized out.) >>=20 >>=20 >> So summarizing some of the failure results so far . . . >>=20 >> The common part of the call chain is: >>=20 >> #0 thr_kill () at thr_kill.S:4 >> #1 __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:48 >> #2 abort () at /usr/src/lib/libc/stdlib/abort.c:61 >> #3 ehooks_debug_zero_check at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170 >> #4 ehooks_alloc at = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:208 >> #5 __je_extent_alloc_wrapper at jemalloc_extent.c:1003 (argument = zero=3Dtrue) >> #6 __je_ecache_alloc_grow at jemalloc_extent.c:126 >> #7 pac_alloc_real at jemalloc_pac.c:124 >> #8 pac_alloc_impl at jemalloc_pac.c:178 >> #9 pai_alloc at = /usr/src/contrib/jemalloc/include/jemalloc/internal/pai.h:43 >> #10 __je_pa_alloc at jemalloc_pa.c:139 >> Note: some #11+ can show arguments with a zero=3Dfalse >>=20 >> All the non-zero Bytes in the pages being checked are 0x5a bytes. >> The zero Bytes (if any) come first so far. >=20 > By no means do I know if the below is the actual problem. >=20 >=20 > The one place I see zero possibly becoming true for > __je_extent_alloc_wrapper by the time of the backtrace > is via: >=20 > void * > extent_alloc_mmap(void *new_addr, size_t size, size_t alignment, bool = *zero, > bool *commit) { > assert(alignment =3D=3D ALIGNMENT_CEILING(alignment, PAGE)); > void *ret =3D pages_map(new_addr, size, alignment, commit); > if (ret =3D=3D NULL) { > return NULL; > } > assert(ret !=3D NULL); > if (*commit) { > *zero =3D true; > } > return ret; > } >=20 > (So pages_map behavior vs. commit usage is relevant. > See jemalloc/src/pages.c .) >=20 > extent_alloc_mmap called via: >=20 > /* > * If the caller specifies (!*zero), it is still possible to receive = zeroed > * memory, in which case *zero is toggled to true. = arena_extent_alloc() takes > * advantage of this to avoid demanding zeroed extents, but taking = advantage of > * them if they are returned. > */ > static void * > extent_alloc_core(tsdn_t *tsdn, arena_t *arena, void *new_addr, size_t = size, > size_t alignment, bool *zero, bool *commit, dss_prec_t dss_prec) { > void *ret; >=20 > assert(size !=3D 0); > assert(alignment !=3D 0); >=20 > /* "primary" dss. */ > if (have_dss && dss_prec =3D=3D dss_prec_primary && (ret =3D > extent_alloc_dss(tsdn, arena, new_addr, size, alignment, = zero, > commit)) !=3D NULL) { > return ret; > } > /* mmap. */ > if ((ret =3D extent_alloc_mmap(new_addr, size, alignment, zero, = commit)) > !=3D NULL) { > return ret; > } > /* "secondary" dss. */ > if (have_dss && dss_prec =3D=3D dss_prec_secondary && (ret =3D > extent_alloc_dss(tsdn, arena, new_addr, size, alignment, = zero, > commit)) !=3D NULL) { > return ret; > } >=20 > /* All strategies for allocation failed. */ > return NULL; > } >=20 > in jemalloc/src/ehooks.c >=20 > called via: >=20 > void * > ehooks_default_alloc_impl(tsdn_t *tsdn, void *new_addr, size_t size, > size_t alignment, bool *zero, bool *commit, unsigned arena_ind) { > arena_t *arena =3D arena_get(tsdn, arena_ind, false); > /* NULL arena indicates arena_create. */ > assert(arena !=3D NULL || alignment =3D=3D HUGEPAGE); > dss_prec_t dss =3D (arena =3D=3D NULL) ? dss_prec_disabled : > (dss_prec_t)atomic_load_u(&arena->dss_prec, = ATOMIC_RELAXED); > void *ret =3D extent_alloc_core(tsdn, arena, new_addr, size, = alignment, > zero, commit, dss); > if (have_madvise_huge && ret) { > pages_set_thp_state(ret, size); > } > return ret; > } >=20 > in jemalloc/src/ehooks.c >=20 > called via (so is ehooks_debug_zero_check): >=20 > static inline void * > ehooks_alloc(tsdn_t *tsdn, ehooks_t *ehooks, void *new_addr, size_t = size, > size_t alignment, bool *zero, bool *commit) { > bool orig_zero =3D *zero; > void *ret; > extent_hooks_t *extent_hooks =3D = ehooks_get_extent_hooks_ptr(ehooks); > if (extent_hooks =3D=3D &ehooks_default_extent_hooks) { > ret =3D ehooks_default_alloc_impl(tsdn, new_addr, size, > alignment, zero, commit, ehooks_ind_get(ehooks)); > } else { > ehooks_pre_reentrancy(tsdn); > ret =3D extent_hooks->alloc(extent_hooks, new_addr, = size, > alignment, zero, commit, ehooks_ind_get(ehooks)); > ehooks_post_reentrancy(tsdn); > } > assert(new_addr =3D=3D NULL || ret =3D=3D NULL || new_addr =3D=3D= ret); > assert(!orig_zero || *zero); > if (*zero && ret !=3D NULL) { > ehooks_debug_zero_check(ret, size); > } > return ret; > } >=20 > called via: >=20 > edata_t * > extent_alloc_wrapper(tsdn_t *tsdn, pac_t *pac, ehooks_t *ehooks, > void *new_addr, size_t size, size_t alignment, bool zero, bool = *commit, > bool growing_retained) { > witness_assert_depth_to_rank(tsdn_witness_tsdp_get(tsdn), > WITNESS_RANK_CORE, growing_retained ? 1 : 0); >=20 > edata_t *edata =3D edata_cache_get(tsdn, pac->edata_cache); > if (edata =3D=3D NULL) { > return NULL; > } > size_t palignment =3D ALIGNMENT_CEILING(alignment, PAGE); > void *addr =3D ehooks_alloc(tsdn, ehooks, new_addr, size, = palignment, > &zero, commit); > . . . >=20 There are just 2 calls to (__je_)pa_alloc, one of which pass false for zero ( jemalloc/src/arena.c ). The pattern used below also matches hpa_alloc but ignore those: # grep -r 'pa_alloc\>' /usr/src/contrib/jemalloc/src/ /usr/src/contrib/jemalloc/src/pa.c:pa_alloc(tsdn_t *tsdn, pa_shard_t = *shard, size_t size, size_t alignment, /usr/src/contrib/jemalloc/src/hpa.c:static edata_t *hpa_alloc(tsdn_t = *tsdn, pai_t *self, size_t size, /usr/src/contrib/jemalloc/src/hpa.c: shard->pai.alloc =3D &hpa_alloc; /usr/src/contrib/jemalloc/src/hpa.c: assert(self->alloc =3D = &hpa_alloc); /usr/src/contrib/jemalloc/src/hpa.c:hpa_alloc(tsdn_t *tsdn, pai_t *self, = size_t size, size_t alignment, bool zero, /usr/src/contrib/jemalloc/src/arena.c: edata_t *edata =3D = pa_alloc(tsdn, &arena->pa_shard, esize, alignment, /usr/src/contrib/jemalloc/src/arena.c: edata_t *slab =3D pa_alloc(tsdn, = &arena->pa_shard, bin_info->slab_size, The calling code looks like the below, where it is the arena_slab_alloc routine that passes false directly. Examples 1, 2, 3, and 5 that I sent to the lists have arena_slab_alloc as the caller of (__je_)pa_alloc. Yet they end up with #5 (__je_)extent_alloc_wrapper showing zero=3Dtrue in the backtrace and ehooks_debug_zero_check being called (which requires ehooks_alloc to see its zero with the relevant value indicating true). That is my evidence for extent_alloc_mmap possibly causing ehooks_alloc to see a true for zero in its check for if it should call ehooks_debug_zero_check . For reference: edata_t * arena_extent_alloc_large(tsdn_t *tsdn, arena_t *arena, size_t usize, size_t alignment, bool zero) { bool deferred_work_generated =3D false; szind_t szind =3D sz_size2index(usize); size_t esize =3D usize + sz_large_pad; =20 bool guarded =3D san_large_extent_decide_guard(tsdn, arena_get_ehooks(arena), esize, alignment); edata_t *edata =3D pa_alloc(tsdn, &arena->pa_shard, esize, = alignment, /* slab */ false, szind, zero, guarded, = &deferred_work_generated); . . . static edata_t * arena_slab_alloc(tsdn_t *tsdn, arena_t *arena, szind_t binind, unsigned = binshard, const bin_info_t *bin_info) { bool deferred_work_generated =3D false; witness_assert_depth_to_rank(tsdn_witness_tsdp_get(tsdn), WITNESS_RANK_CORE, 0); =20 bool guarded =3D san_slab_extent_decide_guard(tsdn, arena_get_ehooks(arena)); edata_t *slab =3D pa_alloc(tsdn, &arena->pa_shard, = bin_info->slab_size, /* alignment */ PAGE, /* slab */ true, /* szind */ binind, /* zero */ false, guarded, &deferred_work_generated); . . . (I do have some more saved core dumps now, but I doubt publication would be all that useful: too similar to those already published.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Nov 19 22:24:16 2025 X-Original-To: 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 4dBbcn4BMBz6GNy4 for ; Wed, 19 Nov 2025 22:24:25 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBbcm6xhmz3NPV for ; Wed, 19 Nov 2025 22:24:24 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-786d1658793so2188917b3.1 for ; Wed, 19 Nov 2025 14:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763591058; x=1764195858; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QHj0H1aLsFR7uKdOxh9u/p22MRQagvQumIS8Sjwq9vA=; b=IiuJNznt5dDt/GvUu4J9wDR1tshDoD12f477nYkvilqIsEefc/eqeiY79cJqjypqc1 uOwKr04+NZJ0nhf8dpmljHvAkY+6MW9QIpgTtCQO+xFPd7/WxjJkg3ciOv7a8bA96xJs NXgOcF2censlfipZr4c9+ldJIUvcJb5EbIcmAsel5a7br1m+FNMjPTRdAgvVytwve0Sy Z1Ad2XLOZO/eD6S+83QSEmrzA0QCYZ2mlLU4RQUgwhtoq7rg2hOfChpOL0+UjWQ969gB YEDHu8M4CUusmjKdsHGIaoxUSMffMYf87CR2J9GlMnM11E+932PvvdWxqFrH/wDjR7oP zFhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763591058; x=1764195858; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QHj0H1aLsFR7uKdOxh9u/p22MRQagvQumIS8Sjwq9vA=; b=PPZCDYdvIoW7OaS8fIouLxjAy+J1jKgxHNiHhNWPO7yleBblDNq/TN9iI8TjYexJ0g 8P7mGs2LXzV5EHu52JXjpKfvC08BGD76o5eWyr1ro5+IH8CiGzXcCqqwPtY9lwhdmEcT qqBgmp+8QL9I6M2pTLQEISEuLW/uMxNQmh9Fxogrdo63wjUIV4p28A1aZbMtf28s7oPO VMflA7DZcOYMJ50gOCmaPfAezMq88I3NjlBNfIILfb29Iq/2q8WSGg7G5edu6z328tTX sy5b583M01goeo0K3GQHMQe9JHvI31Ho4lT3KEWv/jAsR5GYLyqlUVI7kcqZ4TBB/oxe sHgw== X-Gm-Message-State: AOJu0YxxeBwbGZfuDtxDGNDL7RFo+bBa4RVvw1rzRfNH/VFXPAkc45Rl W9ZjEiCISXCssjtOtFY/kuJClJTRr4LCF2GZhvcgMUcGh5CGhyP1TfFx X-Gm-Gg: ASbGncsYn9Y5vlJ1SJMxVs0e9oIwwSneg4FVbpct5ZDyAvdUYAeeO3viMqaPU9i5kRF 9nrSITO1/vKgZ6FfvkdAQXFpyAcyWu2UbSidrX/l9HemgZwjoW92H7i5rBvavDgqrhftjlv60/Y ahOEgC3fxjCX7wTjAMlNmdU2C/OGkl867WeQwl6fMHOBURViCYUlQaYuDkKHRHoVQJCZwYms8C+ Szpvc/ExfsyzY3GyUjkLH+idt6sr15p0kxjRzd6OqTkh6dsTTOjg94SkEcjxRJCTsVEunR2Jdb+ zLGWH6hNj0tKcgGE0Y82xG68jVO96qUEnow1AeFxWX8TOrl4qXYokve0Tvi92nc7Gt+D4LoWzdZ ABXYwE8Xpt3CrnFG8dxcBxnl9CrfHeUdPOb/P7kOWtjTQuHjLuHFNPct+HESsGGOny7MQt5fl0R ivTMT0I51rLmfbbzkVvXn1ATQblSOmsHQhV/91/n9IQxdjlUUxPni5iwJBBpmwtgw5HQ== X-Google-Smtp-Source: AGHT+IG63feHLrlYINpC0iSbBJwj6kJcbZ7BwAmXEIKzEmLXPUc03nO7qXB4FwbJkRwAqRKAEnf7eg== X-Received: by 2002:a05:690c:c3f1:b0:787:bf86:a161 with SMTP id 00721157ae682-78a795a26bamr14956297b3.30.1763591057709; Wed, 19 Nov 2025 14:24:17 -0800 (PST) Received: from ?IPV6:2600:1700:18f0:6812:129a:8666:ef01:3293? ([2600:1700:18f0:6812:129a:8666:ef01:3293]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78a7993e2d6sm2304357b3.39.2025.11.19.14.24.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Nov 2025 14:24:17 -0800 (PST) Message-ID: <531224d3-acaf-4f97-b39c-02b09dcd297c@gmail.com> Date: Wed, 19 Nov 2025 17:24:16 -0500 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: Thunderbird Daily Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' To: Minsoo Choo Cc: FreeBSD Current References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> <60449f55-58e7-4f8b-aa0e-3f288dab5146@gmail.com> Content-Language: en-US From: Ian FREISLICH In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBbcm6xhmz3NPV On 11/19/25 15:42, Minsoo Choo wrote: > On Wednesday, November 19th, 2025 at 2:51 PM, Ian FREISLICH wrote: > >> On 11/19/25 14:24, Minsoo Choo wrote: >> >>> On Wednesday, November 19th, 2025 at 2:19 PM, Ian FREISLICH ianfreislich@gmail.com wrote: >>> >>>> My kernel build started failing recently with the following error. I use >>>> a custom kernel config but looking at NOTES, it's not clear that I've >>>> missed an option that would make it compile. >>>> >>>> In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: >>>> /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared function >>>> 'memmove'; ISO C99 and later do not support implicit function >>>> declarations [-Werror,-Wimplicit-function-declaration] >>>> 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); >>>> >>>> | ^ >>>> 1 error generated. >>>> *** Error code 1 >>>> >>>> I've also tried compiling after blowing away usr/obj. >>>> >>>> Ian >>> >>> memmove is declared in systm.h, but I don't see include statement for systm.h in nvme.h. Could you try including in sys/dev/nvme/nvme.h and build again? >> >> >> It builds with that, but coincidentally GENERIC builds without that change. >> >> Ian > > Could you send your kernel config? Maybe sys/systm.h is included under GENERIC but not under some configs. --X-- cpu HAMMER ident ROUTER makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options NUMA # Non-Uniform Memory Architecture support options PREEMPTION # Enable kernel thread preemption options INET # IPv6 communications protocols options INET6 # IPv6 communications protocols options IPSEC options IPSEC_OFFLOAD # Inline ipsec offload infra options ROUTE_MPATH # Multipath routing support options FIB_ALGO # Modular fib lookups options TCP_OFFLOAD # TCP offload options TCP_BLACKBOX # Enhanced TCP event logging options TCP_HHOOK # hhook(9) framework for TCP options TCP_RFC7413 # TCP Fast Open options SCTP_SUPPORT # Allow kldload of SCTP options KERN_TLS # TLS transmit & receive offload options MAC options MAC_NTPD options MAC_PORTACL options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options ZFS options ZSTDIO options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options TMPFS # Efficient memory filesystem options GEOM_LABEL # Provides labelization options GEOM_PART_GPT options EFIRT # EFI Runtime Services support options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options COMPAT_FREEBSD9 # Compatible with FreeBSD9 options COMPAT_FREEBSD10 # Compatible with FreeBSD10 options COMPAT_FREEBSD11 # Compatible with FreeBSD11 options COMPAT_FREEBSD12 # Compatible with FreeBSD12 options COMPAT_FREEBSD13 # Compatible with FreeBSD13 options COMPAT_FREEBSD14 # Compatible with FreeBSD14 #options COMPAT_FREEBSD15 # Compatible with FreeBSD15 options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB options KDB_UNATTENDED options DDB options GDB options KDB_TRACE options ALT_BREAK_TO_DEBUGGER # Kernel dump features. options EKCD # Support for encrypted kernel dumps options GZIO # gzip-compressed kernel and user dumps options ZSTDIO # zstd-compressed kernel and user dumps options DEBUGNET # debugnet networking options NETDUMP # netdump(4) client support options NETGDB # netgdb(4) client support device pf device pflog device pfsync # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel device cpufreq # Bus support. device acpi device acpi_wmi device smbios device smbus device ichsmb device iicbus device ig4 options IOMMU device pci options PCI_HP # PCI-Express native HotPlug options PCI_IOV # PCI SR-IOV support # ATA controllers device ahci # AHCI-compatible SATA controllers device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct ATA/SCSI access) device ses # Enclosure Services (SES and SAF-TE) # NVM Express (NVMe) support device nvme # base NVMe driver device nvd # expose NVMe namespaces as disks, depends on nvme # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux # keyboard multiplexer # syscons is the legacy console driver, resembling an SCO console #device vga # VGA video card driver #device splash # Splash screen and screen saver support #device sc #options SC_PIXEL_MODE # add support for the raster text mode # vt is the default video console driver device vt device vt_vga device vt_efifb device vt_vbefb device agp # support several AGP chipsets options PPS_SYNC device uart # Generic UART driver device superio device gpio device gpiopps # PCI/PCI-X/PCIe Ethernet NICs that use iflib infrastructure device iflib device igc # Intel I225 2.5G Ethernet device ix # Intel PRO/10GbE PCIE PF Ethernet # Pseudo devices. device crypto # core crypto support device cryptodev device aesni # AES-NI OpenCrypto module device ossl device loop # Network loopback device rdrand_rng # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tuntap # Packet tunnel. device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device firmware # firmware assist module device xz # lzma decompression options EVDEV_SUPPORT device evdev device uinput # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device xhci # XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device usbhid # USB HID Transport device hkbd # HID Keyboard device ukbd # USB Keyboard device umass # Disks/Mass storage - Requires scbus and da # Sound support device sound # Generic sound driver (required) device snd_hda # Intel High Definition Audio # Netmap provides direct access to TX/RX rings on supported NICs device netmap # netmap(4) support device hid # Generic HID support device hidbus # Generic HID Bus # EFI devices device efidev # EFI pseudo-device device efirtc # EFI RTC --X-- From nobody Thu Nov 20 02:04:21 2025 X-Original-To: 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 4dBhVl4vw8z6Ghyg for ; Thu, 20 Nov 2025 02:04:31 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-10699.protonmail.ch (mail-10699.protonmail.ch [79.135.106.99]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBhVl1Dr7z3mXc for ; Thu, 20 Nov 2025 02:04:30 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1763604267; x=1763863467; bh=zf7eJAVWm3nOb7iWNEvHjoHhAppQ+F5+tMziWqEcJ+0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=aBZMEqXywWOranZEQoF8OGJfg7Q4KuSpJv8yIG1hviyfTj7Svqbl2T/A8WhTgTX0M iDU0QJzli1mX0Fb6ltn1qA/YsOFrtKZWTfLmOlHSG6l6+kyfHavL/mL/TJJ5gjRhBr V0pfh6HpnKnkWsaUZbOvyLYqH7WnF6yQKVtR1aqVGaOuFxTrAuOYQLMTRbCbqDwI/O Z/Ootcs6DP60YU7Ob8coln5vCZ9+Ubo4tGBigyCKSFuYO9k2dGZLGNR74VE+HfGV5l UH/PmXthMxnp77J4SfMZSaiLLwhNjGwut3PNZ94dTF2/TD7/cqcvjNVS477X9gDxrx P6wYBVRc4vwRg== Date: Thu, 20 Nov 2025 02:04:21 +0000 To: Ian FREISLICH From: Minsoo Choo Cc: FreeBSD Current Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' Message-ID: In-Reply-To: <531224d3-acaf-4f97-b39c-02b09dcd297c@gmail.com> References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> <60449f55-58e7-4f8b-aa0e-3f288dab5146@gmail.com> <531224d3-acaf-4f97-b39c-02b09dcd297c@gmail.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: d0228ebe7575eba52ad1ce15d47fbb5c3ff9ce07 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBhVl1Dr7z3mXc On Wednesday, November 19th, 2025 at 5:24 PM, Ian FREISLICH wrote: > On 11/19/25 15:42, Minsoo Choo wrote: >=20 > > On Wednesday, November 19th, 2025 at 2:51 PM, Ian FREISLICH ianfreislic= h@gmail.com wrote: > >=20 > > > On 11/19/25 14:24, Minsoo Choo wrote: > > >=20 > > > > On Wednesday, November 19th, 2025 at 2:19 PM, Ian FREISLICH ianfrei= slich@gmail.com wrote: > > > >=20 > > > > > My kernel build started failing recently with the following error= . I use > > > > > a custom kernel config but looking at NOTES, it's not clear that = I've > > > > > missed an option that would make it compile. > > > > >=20 > > > > > In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: > > > > > /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared fu= nction > > > > > 'memmove'; ISO C99 and later do not support implicit function > > > > > declarations [-Werror,-Wimplicit-function-declaration] > > > > > 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); > > > > >=20 > > > > > | ^ > > > > > 1 error generated. > > > > > *** Error code 1 > > > > >=20 > > > > > I've also tried compiling after blowing away usr/obj. > > > > >=20 > > > > > Ian > > > >=20 > > > > memmove is declared in systm.h, but I don't see include statement f= or systm.h in nvme.h. Could you try including in sys/dev/nvme= /nvme.h and build again? > > >=20 > > > It builds with that, but coincidentally GENERIC builds without that c= hange. > > >=20 > > > Ian > >=20 > > Could you send your kernel config? Maybe sys/systm.h is included under = GENERIC but not under some configs. >=20 >=20 > --X-- > cpu HAMMER > ident ROUTER >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug > symbols >=20 > options SCHED_ULE # ULE scheduler > options NUMA # Non-Uniform Memory > Architecture support > options PREEMPTION # Enable kernel thread preemption >=20 > options INET # IPv6 communications protocols > options INET6 # IPv6 communications protocols > options IPSEC > options IPSEC_OFFLOAD # Inline ipsec offload infra > options ROUTE_MPATH # Multipath routing support > options FIB_ALGO # Modular fib lookups > options TCP_OFFLOAD # TCP offload > options TCP_BLACKBOX # Enhanced TCP event logging > options TCP_HHOOK # hhook(9) framework for TCP > options TCP_RFC7413 # TCP Fast Open > options SCTP_SUPPORT # Allow kldload of SCTP > options KERN_TLS # TLS transmit & receive offload > options MAC > options MAC_NTPD > options MAC_PORTACL >=20 > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big > directories > options UFS_GJOURNAL # Enable gjournal-based UFS > journaling > options ZFS > options ZSTDIO > options PROCFS # Process filesystem (requires > PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options TMPFS # Efficient memory filesystem > options GEOM_LABEL # Provides labelization > options GEOM_PART_GPT > options EFIRT # EFI Runtime Services support > options COMPAT_FREEBSD32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > options COMPAT_FREEBSD9 # Compatible with FreeBSD9 > options COMPAT_FREEBSD10 # Compatible with FreeBSD10 > options COMPAT_FREEBSD11 # Compatible with FreeBSD11 > options COMPAT_FREEBSD12 # Compatible with FreeBSD12 > options COMPAT_FREEBSD13 # Compatible with FreeBSD13 > options COMPAT_FREEBSD14 # Compatible with FreeBSD14 > #options COMPAT_FREEBSD15 # Compatible with FreeBSD15 > options KTRACE # ktrace(1) support > options STACK # stack(9) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores >=20 > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options PRINTF_BUFR_SIZE=3D128 # Prevent printf output being > interspersed. > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options HWPMC_HOOKS # Necessary kernel hooks for > hwpmc(4) > options INCLUDE_CONFIG_FILE # Include this file in kernel >=20 > # Debugging support. Always need this: > options KDB > options KDB_UNATTENDED > options DDB > options GDB > options KDB_TRACE > options ALT_BREAK_TO_DEBUGGER >=20 > # Kernel dump features. > options EKCD # Support for encrypted kernel dumps > options GZIO # gzip-compressed kernel and > user dumps > options ZSTDIO # zstd-compressed kernel and > user dumps > options DEBUGNET # debugnet networking > options NETDUMP # netdump(4) client support > options NETGDB # netgdb(4) client support >=20 > device pf > device pflog > device pfsync >=20 > # Make an SMP-capable kernel by default > options SMP # Symmetric MultiProcessor Kernel > device cpufreq >=20 > # Bus support. > device acpi > device acpi_wmi > device smbios > device smbus > device ichsmb > device iicbus > device ig4 > options IOMMU > device pci > options PCI_HP # PCI-Express native HotPlug > options PCI_IOV # PCI SR-IOV support >=20 >=20 > # ATA controllers > device ahci # AHCI-compatible SATA controllers > device scbus # SCSI bus (required for ATA/SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct > ATA/SCSI access) > device ses # Enclosure Services (SES and > SAF-TE) >=20 > # NVM Express (NVMe) support > device nvme # base NVMe driver > device nvd # expose NVMe namespaces as > disks, depends on nvme >=20 > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device kbdmux # keyboard multiplexer >=20 > # syscons is the legacy console driver, resembling an SCO console > #device vga # VGA video card driver > #device splash # Splash screen and screen saver > support > #device sc > #options SC_PIXEL_MODE # add support for the raster > text mode >=20 > # vt is the default video console driver > device vt > device vt_vga > device vt_efifb > device vt_vbefb >=20 > device agp # support several AGP chipsets >=20 > options PPS_SYNC > device uart # Generic UART driver >=20 > device superio > device gpio > device gpiopps >=20 > # PCI/PCI-X/PCIe Ethernet NICs that use iflib infrastructure > device iflib > device igc # Intel I225 2.5G Ethernet > device ix # Intel PRO/10GbE PCIE PF Ethernet >=20 > # Pseudo devices. > device crypto # core crypto support > device cryptodev > device aesni # AES-NI OpenCrypto module > device ossl > device loop # Network loopback > device rdrand_rng # Intel Bull Mountain RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tuntap # Packet tunnel. > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device firmware # firmware assist module > device xz # lzma decompression >=20 > options EVDEV_SUPPORT > device evdev > device uinput >=20 > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter >=20 > # USB support > options USB_DEBUG # enable debug msgs > device uhci # UHCI PCI->USB interface >=20 > device ohci # OHCI PCI->USB interface >=20 > device ehci # EHCI PCI->USB interface (USB 2.0) >=20 > device xhci # XHCI PCI->USB interface (USB 3.0) >=20 > device usb # USB Bus (required) > device usbhid # USB HID Transport > device hkbd # HID Keyboard > device ukbd # USB Keyboard > device umass # Disks/Mass storage - Requires > scbus and da >=20 > # Sound support > device sound # Generic sound driver (required) > device snd_hda # Intel High Definition Audio >=20 > # Netmap provides direct access to TX/RX rings on supported NICs > device netmap # netmap(4) support >=20 > device hid # Generic HID support > device hidbus # Generic HID Bus >=20 > # EFI devices > device efidev # EFI pseudo-device > device efirtc # EFI RTC > --X-- >=20 Could you `make cleankernel` and run `make buildkernel` again? And if it fa= ils for the same reason, could you add `#include ` and `make c= leankernel` then `make buildkernel` again? From nobody Thu Nov 20 02:12:46 2025 X-Original-To: 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 4dBhhL694fz6Gjdk for ; Thu, 20 Nov 2025 02:12:50 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBhhL43Cvz3nmP for ; Thu, 20 Nov 2025 02:12:50 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-787da30c53dso3619757b3.0 for ; Wed, 19 Nov 2025 18:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763604769; x=1764209569; darn=freebsd.org; h=mime-version:subject:user-agent:references:in-reply-to:message-id :date:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=/LBUSsUz6XOlG9qiuXS9nMGcX4lCjn8uXKrOGWcAoOg=; b=iOX8Ig16rMH3Yl0HKDbkayhyHeObSvoQjdeQiusLpiZWSuqCxqlYB3Hp3IUZc+F0Lg lJV43hyXLxXiSkccd31Op/LaMNyGRpdKKNGIziMqI5Sby1XJYtEnj0csXPZ0cZkjqk3h KBN+1m8IBKWBWEzNyzTlLnWRjeA0PJp0ACCkzVNUaaOGM0BfE25mwCxZdL5ZLv2Aybif NyWz5dg76+HpDYo5Wh7q9+ouZBtWyCmM79lfp//RAcKReiXeUXF4SGBwsaDpoAttg6Pu BpuukfUwfgUwGcyUMtiqDumeNeAvoqB+nWHVMY+feV0TcbSmwt1QVI3Sn+VJntc7ILaN V4TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763604769; x=1764209569; h=mime-version:subject:user-agent:references:in-reply-to:message-id :date:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/LBUSsUz6XOlG9qiuXS9nMGcX4lCjn8uXKrOGWcAoOg=; b=ufmFclWkesflkA2y65cGuwMQrJSqzgE//9Z5xzpagcwThLDOl8EtglYUgqUlW0yyPF OPgqQjfDwro5/gHjXLEwm8q7nO4mJMS1qO0Wf8FK4P/LxDEHbjQIhyjW2HaWAxZ3NBE0 R4H+GWE2++i6Xgr0T9NFJGq5jOm4WHMeSUjrVpxPar0xbCIgTotBw3bgofakCAmROI89 /+Nrxuh+EHny9vId2R6FXEbRaFvg4yeKk1el7hmr1yci8vtk5uDCN0devTQhPYe0vwQa 4t4SVXGVnaOgfian5FmL+f1VcbTUmP7v9W3njvUMpHmcz4qNWjIHGM6LjzCBqN1iXlXx Iy/g== X-Gm-Message-State: AOJu0YyE11faOTvoonC8kx17USUdg1hip6Jud3mZWuLQHYW9QDgzr6ex mwdINZBS/JvqrdT1Kl2HkiS+TjnHh30RqkbTIUr4gBAwLjQNMe8fnPDVenlUK1U9 X-Gm-Gg: ASbGncsCraZMY09LTPK7ZsdOPE+Wl7jMBXG/AKWQNdM26YdfbrQ38C3dQq1QKy3LcUW XYwxqHXaray6xMlNixghAcXV8JZ8lzyHTLTbKqb47ecVlKynqIJbsKD68Sc7Zh1zzD1UY1nzDyl DdP1dPR33sVkX76auAQeqx7uaMw5kAGWRRhs3uB0aZAJlaaVUJOT4ZFZFx1Xn8XaWPmaLbP8xkO KMN1wqLVgX8rAkHf4Hp+SBDi8Ge8FUXJ15v8+vYDUMmzxQdeMS+hpBH16YvozFC2QiQV5RZ4g1K v0nBcTlWnhqjV4YulEUusw+TUz/E+GMa6CtLSGH0vuX83jlFnZYDNuzxTLmKDATS+ig5kfrqXRb H96z6kSfj/egSFHJX+TOnRbCXhXNmLp/lAky0TXtsPMBGIcDR9UH/ec0foAvNm9v8eYVgLedNb3 BCOPwfJQMbW8Ejvys6Xtc467iR/SSPNMPIhK8oPquVv6XRbX0NNR3F6Q3ugtQGvIRrcW8= X-Google-Smtp-Source: AGHT+IFA8yO5t5gxm5E7Jiq8VFlkSpGpojTRC65dZN4YHkl9S3nR0EIv+/5vygu/NRYfgODUBnlpNA== X-Received: by 2002:a05:690c:350d:b0:783:afee:fc46 with SMTP id 00721157ae682-78a7abfb922mr8838257b3.37.1763604768609; Wed, 19 Nov 2025 18:12:48 -0800 (PST) Received: from [10.0.0.133] (107-128-20-168.lightspeed.tukrga.sbcglobal.net. [107.128.20.168]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78a798a82a0sm3730897b3.17.2025.11.19.18.12.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Nov 2025 18:12:47 -0800 (PST) From: Ian Freislich To: Minsoo Choo CC: FreeBSD Current Date: Wed, 19 Nov 2025 21:12:46 -0500 Message-ID: <19a9f091d30.27e6.64e08aff09ba5a21b2fc9010d26a90e5@gmail.com> In-Reply-To: References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> <60449f55-58e7-4f8b-aa0e-3f288dab5146@gmail.com> <531224d3-acaf-4f97-b39c-02b09dcd297c@gmail.com> User-Agent: AquaMail/1.55.2 (build: 105502562) Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' 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: multipart/alternative; boundary="19a9f0920d1632027e66b8608a" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBhhL43Cvz3nmP This is a multi-part message in MIME format. --19a9f0920d1632027e66b8608a Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit On November 19, 2025 21:04:28 Minsoo Choo wrote: > On Wednesday, November 19th, 2025 at 5:24 PM, Ian FREISLICH > wrote: > >> On 11/19/25 15:42, Minsoo Choo wrote: >> >>> On Wednesday, November 19th, 2025 at 2:51 PM, Ian FREISLICH >>> ianfreislich@gmail.com wrote: >>> >>>> On 11/19/25 14:24, Minsoo Choo wrote: >>>> >>>>> On Wednesday, November 19th, 2025 at 2:19 PM, Ian FREISLICH >>>>> ianfreislich@gmail.com wrote: >>>>> >>>>>> My kernel build started failing recently with the following error. I use >>>>>> a custom kernel config but looking at NOTES, it's not clear that I've >>>>>> missed an option that would make it compile. >>>>>> >>>>>> In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: >>>>>> /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared function >>>>>> 'memmove'; ISO C99 and later do not support implicit function >>>>>> declarations [-Werror,-Wimplicit-function-declaration] >>>>>> 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); >>>>>> >>>>>> | ^ >>>>>> 1 error generated. >>>>>> *** Error code 1 >>>>>> >>>>>> I've also tried compiling after blowing away usr/obj. >>>>>> >>>>>> Ian >>>>> >>>>> memmove is declared in systm.h, but I don't see include statement for >>>>> systm.h in nvme.h. Could you try including in >>>>> sys/dev/nvme/nvme.h and build again? >>>> >>>> It builds with that, but coincidentally GENERIC builds without that change. >>>> >>>> Ian >>> >>> Could you send your kernel config? Maybe sys/systm.h is included under >>> GENERIC but not under some configs. >> >> >> --X-- >> cpu HAMMER >> ident ROUTER >> >> makeoptions DEBUG=-g # Build kernel with gdb(1) debug >> symbols >> >> options SCHED_ULE # ULE scheduler >> options NUMA # Non-Uniform Memory >> Architecture support >> options PREEMPTION # Enable kernel thread preemption >> >> options INET # IPv6 communications protocols >> options INET6 # IPv6 communications protocols >> options IPSEC >> options IPSEC_OFFLOAD # Inline ipsec offload infra >> options ROUTE_MPATH # Multipath routing support >> options FIB_ALGO # Modular fib lookups >> options TCP_OFFLOAD # TCP offload >> options TCP_BLACKBOX # Enhanced TCP event logging >> options TCP_HHOOK # hhook(9) framework for TCP >> options TCP_RFC7413 # TCP Fast Open >> options SCTP_SUPPORT # Allow kldload of SCTP >> options KERN_TLS # TLS transmit & receive offload >> options MAC >> options MAC_NTPD >> options MAC_PORTACL >> >> options FFS # Berkeley Fast Filesystem >> options SOFTUPDATES # Enable FFS soft updates support >> options UFS_ACL # Support for access control lists >> options UFS_DIRHASH # Improve performance on big >> directories >> options UFS_GJOURNAL # Enable gjournal-based UFS >> journaling >> options ZFS >> options ZSTDIO >> options PROCFS # Process filesystem (requires >> PSEUDOFS) >> options PSEUDOFS # Pseudo-filesystem framework >> options TMPFS # Efficient memory filesystem >> options GEOM_LABEL # Provides labelization >> options GEOM_PART_GPT >> options EFIRT # EFI Runtime Services support >> options COMPAT_FREEBSD32 # Compatible with i386 binaries >> options COMPAT_FREEBSD4 # Compatible with FreeBSD4 >> options COMPAT_FREEBSD5 # Compatible with FreeBSD5 >> options COMPAT_FREEBSD6 # Compatible with FreeBSD6 >> options COMPAT_FREEBSD7 # Compatible with FreeBSD7 >> options COMPAT_FREEBSD9 # Compatible with FreeBSD9 >> options COMPAT_FREEBSD10 # Compatible with FreeBSD10 >> options COMPAT_FREEBSD11 # Compatible with FreeBSD11 >> options COMPAT_FREEBSD12 # Compatible with FreeBSD12 >> options COMPAT_FREEBSD13 # Compatible with FreeBSD13 >> options COMPAT_FREEBSD14 # Compatible with FreeBSD14 >> #options COMPAT_FREEBSD15 # Compatible with FreeBSD15 >> options KTRACE # ktrace(1) support >> options STACK # stack(9) support >> options SYSVSHM # SYSV-style shared memory >> options SYSVMSG # SYSV-style message queues >> options SYSVSEM # SYSV-style semaphores >> >> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time >> extensions >> options PRINTF_BUFR_SIZE=128 # Prevent printf output being >> interspersed. >> options KBD_INSTALL_CDEV # install a CDEV entry in /dev >> options HWPMC_HOOKS # Necessary kernel hooks for >> hwpmc(4) >> options INCLUDE_CONFIG_FILE # Include this file in kernel >> >> # Debugging support. Always need this: >> options KDB >> options KDB_UNATTENDED >> options DDB >> options GDB >> options KDB_TRACE >> options ALT_BREAK_TO_DEBUGGER >> >> # Kernel dump features. >> options EKCD # Support for encrypted kernel dumps >> options GZIO # gzip-compressed kernel and >> user dumps >> options ZSTDIO # zstd-compressed kernel and >> user dumps >> options DEBUGNET # debugnet networking >> options NETDUMP # netdump(4) client support >> options NETGDB # netgdb(4) client support >> >> device pf >> device pflog >> device pfsync >> >> # Make an SMP-capable kernel by default >> options SMP # Symmetric MultiProcessor Kernel >> device cpufreq >> >> # Bus support. >> device acpi >> device acpi_wmi >> device smbios >> device smbus >> device ichsmb >> device iicbus >> device ig4 >> options IOMMU >> device pci >> options PCI_HP # PCI-Express native HotPlug >> options PCI_IOV # PCI SR-IOV support >> >> >> # ATA controllers >> device ahci # AHCI-compatible SATA controllers >> device scbus # SCSI bus (required for ATA/SCSI) >> device ch # SCSI media changers >> device da # Direct Access (disks) >> device sa # Sequential Access (tape etc) >> device cd # CD >> device pass # Passthrough device (direct >> ATA/SCSI access) >> device ses # Enclosure Services (SES and >> SAF-TE) >> >> # NVM Express (NVMe) support >> device nvme # base NVMe driver >> device nvd # expose NVMe namespaces as >> disks, depends on nvme >> >> # atkbdc0 controls both the keyboard and the PS/2 mouse >> device atkbdc # AT keyboard controller >> device atkbd # AT keyboard >> device kbdmux # keyboard multiplexer >> >> # syscons is the legacy console driver, resembling an SCO console >> #device vga # VGA video card driver >> #device splash # Splash screen and screen saver >> support >> #device sc >> #options SC_PIXEL_MODE # add support for the raster >> text mode >> >> # vt is the default video console driver >> device vt >> device vt_vga >> device vt_efifb >> device vt_vbefb >> >> device agp # support several AGP chipsets >> >> options PPS_SYNC >> device uart # Generic UART driver >> >> device superio >> device gpio >> device gpiopps >> >> # PCI/PCI-X/PCIe Ethernet NICs that use iflib infrastructure >> device iflib >> device igc # Intel I225 2.5G Ethernet >> device ix # Intel PRO/10GbE PCIE PF Ethernet >> >> # Pseudo devices. >> device crypto # core crypto support >> device cryptodev >> device aesni # AES-NI OpenCrypto module >> device ossl >> device loop # Network loopback >> device rdrand_rng # Intel Bull Mountain RNG >> device ether # Ethernet support >> device vlan # 802.1Q VLAN support >> device tuntap # Packet tunnel. >> device md # Memory "disks" >> device gif # IPv6 and IPv4 tunneling >> device firmware # firmware assist module >> device xz # lzma decompression >> >> options EVDEV_SUPPORT >> device evdev >> device uinput >> >> # The `bpf' device enables the Berkeley Packet Filter. >> # Be aware of the administrative consequences of enabling this! >> # Note that 'bpf' is required for DHCP. >> device bpf # Berkeley packet filter >> >> # USB support >> options USB_DEBUG # enable debug msgs >> device uhci # UHCI PCI->USB interface >> >> device ohci # OHCI PCI->USB interface >> >> device ehci # EHCI PCI->USB interface (USB 2.0) >> >> device xhci # XHCI PCI->USB interface (USB 3.0) >> >> device usb # USB Bus (required) >> device usbhid # USB HID Transport >> device hkbd # HID Keyboard >> device ukbd # USB Keyboard >> device umass # Disks/Mass storage - Requires >> scbus and da >> >> # Sound support >> device sound # Generic sound driver (required) >> device snd_hda # Intel High Definition Audio >> >> # Netmap provides direct access to TX/RX rings on supported NICs >> device netmap # netmap(4) support >> >> device hid # Generic HID support >> device hidbus # Generic HID Bus >> >> # EFI devices >> device efidev # EFI pseudo-device >> device efirtc # EFI RTC >> --X-- > > Could you `make cleankernel` and run `make buildkernel` again? And if it > fails for the same reason, could you add `#include ` and `make > cleankernel` then `make buildkernel` again? I did rm -rf /usr/obj/* and rebuilt before reporting. --19a9f0920d1632027e66b8608a Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On November 19, 2025 21:= 04:28 Minsoo Choo <minsoochoo0122@proton.me> wrote:

On Wednesday, November 19th, 2025 at 5:24 PM, Ian FREISLI= CH <ianfreislich@gmail.com> wrote:

On 11/19/25 15:42, Minsoo Choo wrote:

On Wednesday, November 19th, 2025 at 2:51 PM, Ian FREISLI= CH ianfreislich@gmail.com wrote:

On 11/19/25 14:24, Minsoo Choo wrote:

On Wednesday, November 19th, 2025 at 2:19 PM, Ian FREISLI= CH ianfreislich@gmail.com wrote:

My kernel build started failing recently with the followi= ng error. I use
a custom kernel config but looking at NOTES, it's not cle= ar that I've
missed an option that would make it compile.

In file included from /usr/src/sys/dev/nvme/nvme_util.c:3= 4:
/usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undec= lared function
'memmove'; ISO C99 and later do not support implicit func= tion
declarations [-Werror,-Wimplicit-function-declaration]
2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGT= H);

| ^
1 error generated.
*** Error code 1

I've also tried compiling after blowing away usr/obj.

Ian

memmove is declared in systm.h, but I don't see include s= tatement for systm.h in nvme.h. Could you try including <sys/systm.h>= in sys/dev/nvme/nvme.h and build again?

It builds with that, but coincidentally GENERIC builds wi= thout that change.

Ian

Could you send your kernel config? Maybe sys/systm.h is i= ncluded under GENERIC but not under some configs.


--X--
cpu HAMMER
ident ROUTER

makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug
symbols

options SCHED_ULE # ULE scheduler
options NUMA # Non-Uniform Memory
Architecture support
options PREEMPTION # Enable kernel thread preemption

options INET # IPv6 communications protocols
options INET6 # IPv6 communications protocols
options IPSEC
options IPSEC_OFFLOAD # Inline ipsec offload infra
options ROUTE_MPATH # Multipath routing support
options FIB_ALGO # Modular fib lookups
options TCP_OFFLOAD # TCP offload
options TCP_BLACKBOX # Enhanced TCP event logging
options TCP_HHOOK # hhook(9) framework for TCP
options TCP_RFC7413 # TCP Fast Open
options SCTP_SUPPORT # Allow kldload of SCTP
options KERN_TLS # TLS transmit & receive offload
options MAC
options MAC_NTPD
options MAC_PORTACL

options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big
directories
options UFS_GJOURNAL # Enable gjournal-based UFS
journaling
options ZFS
options ZSTDIO
options PROCFS # Process filesystem (requires
PSEUDOFS)
options PSEUDOFS # Pseudo-filesystem framework
options TMPFS # Efficient memory filesystem
options GEOM_LABEL # Provides labelization
options GEOM_PART_GPT
options EFIRT # EFI Runtime Services support
options COMPAT_FREEBSD32 # Compatible with i386 binaries<= /div>
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options COMPAT_FREEBSD9 # Compatible with FreeBSD9
options COMPAT_FREEBSD10 # Compatible with FreeBSD10
options COMPAT_FREEBSD11 # Compatible with FreeBSD11
options COMPAT_FREEBSD12 # Compatible with FreeBSD12
options COMPAT_FREEBSD13 # Compatible with FreeBSD13
options COMPAT_FREEBSD14 # Compatible with FreeBSD14
#options COMPAT_FREEBSD15 # Compatible with FreeBSD15
options KTRACE # ktrace(1) support
options STACK # stack(9) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores

options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real= -time
extensions
options PRINTF_BUFR_SIZE=3D128 # Prevent printf output be= ing
interspersed.
options KBD_INSTALL_CDEV # install a CDEV entry in /dev
options HWPMC_HOOKS # Necessary kernel hooks for
hwpmc(4)
options INCLUDE_CONFIG_FILE # Include this file in kernel=

# Debugging support. Always need this:
options KDB
options KDB_UNATTENDED
options DDB
options GDB
options KDB_TRACE
options ALT_BREAK_TO_DEBUGGER

# Kernel dump features.
options EKCD # Support for encrypted kernel dumps
options GZIO # gzip-compressed kernel and
user dumps
options ZSTDIO # zstd-compressed kernel and
user dumps
options DEBUGNET # debugnet networking
options NETDUMP # netdump(4) client support
options NETGDB # netgdb(4) client support

device pf
device pflog
device pfsync

# Make an SMP-capable kernel by default
options SMP # Symmetric MultiProcessor Kernel
device cpufreq

# Bus support.
device acpi
device acpi_wmi
device smbios
device smbus
device ichsmb
device iicbus
device ig4
options IOMMU
device pci
options PCI_HP # PCI-Express native HotPlug
options PCI_IOV # PCI SR-IOV support


# ATA controllers
device ahci # AHCI-compatible SATA controllers
device scbus # SCSI bus (required for ATA/SCSI)
device ch # SCSI media changers
device da # Direct Access (disks)
device sa # Sequential Access (tape etc)
device cd # CD
device pass # Passthrough device (direct
ATA/SCSI access)
device ses # Enclosure Services (SES and
SAF-TE)

# NVM Express (NVMe) support
device nvme # base NVMe driver
device nvd # expose NVMe namespaces as
disks, depends on nvme

# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc # AT keyboard controller
device atkbd # AT keyboard
device kbdmux # keyboard multiplexer

# syscons is the legacy console driver, resembling an SCO= console
#device vga # VGA video card driver
#device splash # Splash screen and screen saver
support
#device sc
#options SC_PIXEL_MODE # add support for the raster
text mode

# vt is the default video console driver
device vt
device vt_vga
device vt_efifb
device vt_vbefb

device agp # support several AGP chipsets

options PPS_SYNC
device uart # Generic UART driver

device superio
device gpio
device gpiopps

# PCI/PCI-X/PCIe Ethernet NICs that use iflib infrastruct= ure
device iflib
device igc # Intel I225 2.5G Ethernet
device ix # Intel PRO/10GbE PCIE PF Ethernet

# Pseudo devices.
device crypto # core crypto support
device cryptodev
device aesni # AES-NI OpenCrypto module
device ossl
device loop # Network loopback
device rdrand_rng # Intel Bull Mountain RNG
device ether # Ethernet support
device vlan # 802.1Q VLAN support
device tuntap # Packet tunnel.
device md # Memory "disks"
device gif # IPv6 and IPv4 tunneling
device firmware # firmware assist module
device xz # lzma decompression

options EVDEV_SUPPORT
device evdev
device uinput

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling= this!
# Note that 'bpf' is required for DHCP.
device bpf # Berkeley packet filter

# USB support
options USB_DEBUG # enable debug msgs
device uhci # UHCI PCI->USB interface

device ohci # OHCI PCI->USB interface

device ehci # EHCI PCI->USB interface (USB 2.0)

device xhci # XHCI PCI->USB interface (USB 3.0)

device usb # USB Bus (required)
device usbhid # USB HID Transport
device hkbd # HID Keyboard
device ukbd # USB Keyboard
device umass # Disks/Mass storage - Requires
scbus and da

# Sound support
device sound # Generic sound driver (required)
device snd_hda # Intel High Definition Audio

# Netmap provides direct access to TX/RX rings on support= ed NICs
device netmap # netmap(4) support

device hid # Generic HID support
device hidbus # Generic HID Bus

# EFI devices
device efidev # EFI pseudo-device
device efirtc # EFI RTC
--X--


Could you `make cleankernel` and run `make buildkernel` a= gain? And if it fails for the same reason, could you add `#include <sys/= systm.h>` and `make cleankernel` then `make buildkernel` again?

I did rm -rf /usr/obj/*= and rebuilt before reporting.
--19a9f0920d1632027e66b8608a-- From nobody Thu Nov 20 04:51:39 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 4dBmCp72npz6GwqM for ; Thu, 20 Nov 2025 04:51:50 +0000 (UTC) (envelope-from cyric@mm.st) Received: from fhigh-b1-smtp.messagingengine.com (fhigh-b1-smtp.messagingengine.com [202.12.124.152]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBmCp2Kdfz45fg for ; Thu, 20 Nov 2025 04:51:50 +0000 (UTC) (envelope-from cyric@mm.st) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mm.st header.s=fm3 header.b=kV+HtO9P; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="hTU9/dlm"; dmarc=pass (policy=none) header.from=mm.st; spf=pass (mx1.freebsd.org: domain of cyric@mm.st designates 202.12.124.152 as permitted sender) smtp.mailfrom=cyric@mm.st Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id B1B1E7A016B for ; Wed, 19 Nov 2025 23:51:48 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Wed, 19 Nov 2025 23:51:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mm.st; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1763614308; x=1763700708; bh=P4yT4IGN0nQZas/QHxdW3i9C7JZzUYElUJzT1HPy8jQ=; b= kV+HtO9PEkQGXo1RXZBnjWWJTFwNS1XH/2RV6prKl0dImwCuq5VdUHSElmQfYzkG GJh3cRmkFAr7aXOEqlr5eeEKBiBsndfSm+SLu7L1KBrxYFXPicud0r1t1tDGP31j gLrpV66KFIEnUhCAUMP/JwvqvFADhEx+tn/KVyBFaNvYdYBM4QI2CCBJ/6o4GEtb eSQyAt7rg7IsVsH53GWsxQHdXbfiU6SogsW+hd8joSGT+6jm00L99mUFTP2PrvRp 9WOK0+rUpcnFnjRLJKnzAtorf9TsU0vxk/eh9N0IyYCm+kw9WXoDDR0/3Zbf6CTH Nvczz3d7ahbuSH4qD33RjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1763614308; x=1763700708; bh=P 4yT4IGN0nQZas/QHxdW3i9C7JZzUYElUJzT1HPy8jQ=; b=hTU9/dlm+2mXMHkgn CBCrWJRQuYVyGKyxppNZJYbfadGd1S75hAUyYqd6N5qkNF5yRX6C1eiDOzeRXMtB Sw6s8urKOvrncn6ucPiz5XrAuT248EUZIvNw4CiEdpusjMAuEv38SuUkVQQiaZkI N4eDG8ckG/hQ2tvHm31E2voHtt1J+HYHqkm9hZFOf6jVWvgNL9p7cZog9TPyla+y bvhwbDskrmRlJXlNjXLtuXu9s7IyWEnl8zYhGegAOhfu1sML7XrbG7YXpiqaQjgv KQaGvelUVPpqXhpnXIegvbJuK/odynDodpJeTnsofdXl8KOp6XbVIz7HETgrWvdx WCShA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdeiudejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertd dtvdejnecuhfhrohhmpegthihrihgtsehmmhdrshhtnecuggftrfgrthhtvghrnhepgeff jeffudfffeeuleefkedtgfekjeetledtledvudethfeugeefieethfdutedunecuffhomh grihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomheptgihrhhitgesmhhmrdhsthdpnhgspghrtghpthhtohepud dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: icc3648d4:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 19 Nov 2025 23:51:47 -0500 (EST) Message-ID: Date: Thu, 20 Nov 2025 11:51:39 +0700 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 Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' To: freebsd-current@freebsd.org References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> Content-Language: en-US From: cyric@mm.st In-Reply-To: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[mm.st,none]; R_DKIM_ALLOW(-0.20)[mm.st:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.152:from]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[mm.st]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEMAIL_ENVFROM(0.00)[mm.st]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[mm.st:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4dBmCp2Kdfz45fg Ian FREISLICH wrote: > My kernel build started failing recently with the following error. I use > a custom kernel config but looking at NOTES, it's not clear that I've > missed an option that would make it compile. > > In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: > /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared function > 'memmove'; ISO C99 and later do not support implicit function > declarations [-Werror,-Wimplicit-function-declaration] >  2012 |         memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); >       |         ^ > 1 error generated. > *** Error code 1 > > I've also tried compiling after blowing away usr/obj. It seems to be the following commit: https://cgit.freebsd.org/src/commit/?id=8d2a50bb38051fefeb1427fdbfd249f2829310d8 And it was reported: https://lists.freebsd.org/archives/dev-commits-src-main/2025-November/037599.html From nobody Thu Nov 20 05:08:24 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 4dBmb401glz6GxvD for ; Thu, 20 Nov 2025 05:08:32 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-10696.protonmail.ch (mail-10696.protonmail.ch [79.135.106.96]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBmb33wfDz485v for ; Thu, 20 Nov 2025 05:08:31 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1763615307; x=1763874507; bh=WyEGCDs5s48Ler4JU3AQ1xTsr4Tmzwfjf/gpYR+xEGw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=SdtzePjdUVc7dlyYRZ2Zbev+Ua0yjhYSycgm+QhkGfnU7iXi5IKSY8YMjuJtRJQ/O 0zCrwTQ9QIfAFj5DWClZwfqWcnywpAa+nP2Wc/RsS+O+wUrrYqnmh4wgQiCamFSt/0 a5qLzcK0grr/vC5JOjNqnnZGQ+EkPoSHvA/1SRycLWDKU0a4rin03GFCZoX060Xj1D TSE8serMBbvqeJcAdWdylUxvhQV9hplS891dDMVqWa3qqg9jlwln+qk28fGnt2PRSd 3fr+NPhqppeAnDlkNtfcDOdtm64uf7u6OQ3AS/t4dVThXRJOddgdhlVUdraWQ3fK6f ONOfw3moORy/A== Date: Thu, 20 Nov 2025 05:08:24 +0000 To: cyric@mm.st From: Minsoo Choo Cc: freebsd-current@freebsd.org Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' Message-ID: In-Reply-To: References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 1f59558bdfd98f63e6dc6929898969102d217e36 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dBmb33wfDz485v On Wednesday, November 19th, 2025 at 11:52 PM, cyric@mm.st wr= ote: > Ian FREISLICH wrote: >=20 > > My kernel build started failing recently with the following error. I us= e > > a custom kernel config but looking at NOTES, it's not clear that I've > > missed an option that would make it compile. > >=20 > > In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: > > /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared function > > 'memmove'; ISO C99 and later do not support implicit function > > declarations [-Werror,-Wimplicit-function-declaration] > > 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); > > | ^ > > 1 error generated. > > *** Error code 1 > >=20 > > I've also tried compiling after blowing away usr/obj. >=20 >=20 > It seems to be the following commit: >=20 > https://cgit.freebsd.org/src/commit/?id=3D8d2a50bb38051fefeb1427fdbfd249f= 2829310d8 >=20 > And it was reported: >=20 > https://lists.freebsd.org/archives/dev-commits-src-main/2025-November/037= 599.html Thanks for figuring this out. I will see if adding #include s= olves this issue and try to create pr by tomorrow. From nobody Thu Nov 20 08:44:37 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 4dBsNm40QLz6HFyx for ; Thu, 20 Nov 2025 08:44:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4dBsNk4Yj9z3VlV for ; Thu, 20 Nov 2025 08:44:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DNvKMVGk; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763628290; bh=5YbTsqH4spwyWUl5oA7naxTo4GnXu9O4uj9KD1oOHHs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=DNvKMVGkYUUhNAwUXxrqAKtbooWd5yIv/6jZOvuFz4YwH5zK/paSyyHnYgs/wO8gL0MkoPO0JOnrtMOxn6G5fXZx3vMN3/s820suCL/9n9gRq2VrcNcr+2nsgVZfBl32ttmKN1j7+r5iLYBMP1QjttuOjO1fmwZOE5iJvGp/hHyG2gwfD6qDoNgElWYpvEgs533qV+ifzOyOqAOusotHAX898uG80d/N4uswdNIFmqsu/DrZ6r0Dtov3LB49XUfrDX16XUi/cHsXlmdQoaMrA24LbPitphnX5aPmeHVJUUc8ORlqR3Waru74SWHNzczzPpryBg7W35bkNb5YBwEK1Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763628290; bh=PowljTrHdCHk+Cw3L6q8fsAAXpzw2cZD7UPCeb1OVV+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QV9MGiWDGQn3FOmOFBcSp+0roVGD67jbrpNuNbkvyd5s7aGihIXa4j2n9EsDJ9I2sUAYn8nWMKri6ccsydp0Sx5XYhNb/1ZLFN/j61KCYYCVGUgrMjWryyFrt7PxjTFfEuEbioxwH6IbWNraJAoFCwQyQlOVLhO/wlMreu2nrhDLXJREWy1mCrQiHlOwndrYl2NjdKG6+VMJBkC+sA/tBhl3I9IAfar+TJoyM6PxjJFx+NtuZE/TVr+u1FlLP0k+KoexDgGnkAf0N1/OLBIDe+Ei4PfqOaoRAJ7Z9/IuDtqiswzQ9OH82cEAv3iPD5RXextmCPiyw59DZC/ZxbBpPw== X-YMail-OSG: srxAinYVM1lFm4KPvUvQKPpH0Ds9B6_PmBYlPzaZNPuUsU.SdN2ukDrOXLoq9qn boACsQjm4VVGl2U.lWhmM9wC5jNFvtD.MKEi6hR6AyHaVjTsqRazpG6uDlJKzcszfv.L2KucDpj5 3OAxJkVpXGoMU7WVO8Cc3L0rOZ.McDTY4jNn6k7qMDVPVVlvywGOnNeHUC4ju2TvsgXrVq_P9N5B jIs1fQzoublMKIlhB9vvAHPTSo4d1W7XECUsfndK_HTUH9sTVsNaaV5V1KbopqVWk0.V3cSdyJaM kWreMxKY9OpkyQBLZztz6cd4vJ.gCJXfe_rVI7OqoTG7wG2bABCnPF_0H7tG7mkg.uVeyo0lMAEC NyknwJ4kHUuW4KSft7zBPds8fo7u6E2FYxTSSiR.PgA6jZv1Q4wua3Bx8D07NzKWBt9En33ViliL RO5285dAVTvTL1UTbnRLtI3E4.iVGcO.DGHU8Eq4HY5BAlS5YDprUYzEMFj8B6QTTIOq0jv6dEld qKRXaCcfRXNNVs1uICS8VHyxjWmz9gd0fvHTfO54lLAFVB2FTZE7cF7ty796FFJIDikQw1V6.WTw IiLX_aJRHCrYhse0y7vh_pa1fx51A4oi.JGjlsf40TnJ8BPPQP1CwOf9FrvC6jy9CGtCZ7XDCmK3 qePwxiJFMEtbdkyOtEd.IGOMGtPRByVTwfzC9jweZVrBIf1fGbbcAXf5IN.yCX1jSBJNoCN4bdjB 4t50msqLJZ9t9j32BCQzaFoqqc0I9WrtMKfInMO4G9L4sAoO2raBhmoulGFExZW4CsjPOZYHJzRN DyaAcqqpBCIqLCJcEsL9naHdW4CyWQ50_6DMaX0BeXBtSII675f8qDEiH9mtaETFdXwqHDUy1M3W ZlOGYdIotGJ.6TikBNoSulc8NGcvTZIIxqDGMT6f8DvExfy6KMRMgqgchhqX_rNI0SGZt.LAMjYu kKIffAYCV7DC.qOaVYQ2w0bscLMJNH.jM4krokef92FLp3Fd0HBHpNWv66YhSeRDQ.a3_Zy22Aae zWN2tF.kmVxeqrtdzyXMB0bqpS_b9V2TZ.Ce7GP5epifffunB_226kZ5SVYXUn.U4ArOrdVMCKdS TA9HgRfoY7i99no.zU5DDXUky3EDb1r5LF.MAo7xvR7VJn6wH.hwWGRKNZKmH54CK7xE5WgFI5d. eHM1MUYBZBugfAyqQixhdvFRaEbfzW7FlgweypxalCwYsMnHMlwrw_lVWJHj1Fb5itmaIBGZ8Ffr BkKofF9uDUsAZagyHNPhPM9KEGX_ydUNZCy23nRRZpynBIHBzcZU4SAUkwxtHcLGn1kIIgF3sFZo bSyd_keXDoj5EIAxyEIHG2sbm32wNpZUEkFm7fPWwBeytqLXuPc0aGckTLut.T0dLXEEOdKRgoey cF3WLeo4Q1Z8_QVDOcyr2jAPqt0rB0BBUe_efmMGQ5lyJCNr1Rig73tNgKdO2HmIlR3eQKsBpKGb GeftuiEUijpqpKxEVwPMtTB2gsN.i1JTupVkd4gxAc55xRIbkaDaKXgifvJU6uC2ylpA9AQiTf7K 72tLkgGgrZ4j4QLkzPyz4u8_mvGLxhDCBtmFK5.kqY23LL_zkCljQtRft4CpsZSb1ehPZGizxe8M rHG3MCeKER1PLgdHRPVxGO5gNN9ah6_5gvYinaMWIDKf3oFSSpNUEZ9heT6je40xznU6PJfNy9oD MChXEwxRLU1VQoSov2j8bEAiqNF3DulabrnPpUD49errFl99V.yPgusJMiMdHkhB.dH5OHYAvEfk t3V6TpE9dpsLl6lsd6HZtAvPo_cHbZCBXOu2PXi9MFBkTO_BgGRSc.FQXVQttB0zBFd9OOkQ712H Y7MliJRtYHlIvOuFRXS1mXDrFJhfRCRZl7vQEzrwNuyMIBCeQCKzlgOr1s65YGEA0F.mQAL3M1Ee CyHmIkMUtMoigMHjQlhAas25Ht3pwkZGx0PVTjDbJLJEiX19chKWYtZfMOtndE6vlKR2yqB94Mq0 l.7C5e9E698X5q4u_uXIO01axVQYh82GuHQcxCO1ckQzQqSLuotAQfFwUMcvWcVv5G7W4_gkgqxC RLGoVKKKHlMGuk0S67JJe6.xsyezKaaCtaDNmGvw_s6gTz7nSXS9wX2uNBiOoZC5v3bF5jAMciIy eWV02ee4sCA0.gIv0yGxjCYMvs8sBgOzt4LWfEOdyZaz_o2iQqbjlDLMbEtAQyURsNRIaQD1tmyk mr5l2qJaCgbzynk5KIzMPMvrlqQvVF3WQ5lK1XgJMq0x07AJpodYsTC6JCNOEnU5YbYN.8UXRrKk - X-Sonic-MF: X-Sonic-ID: b8a1bfc0-e0cc-4443-819b-33e024f9d64b Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Nov 2025 08:44:50 +0000 Received: by hermes--production-gq1-869cc4b577-mslht (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 672a14f4379293d44b93c410f7edde1e; Thu, 20 Nov 2025 08:44:48 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: changing from pkgbase to regularbase Message-Id: Date: Thu, 20 Nov 2025 00:44:37 -0800 To: grembo@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.53 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.53)[-0.532]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from] X-Rspamd-Queue-Id: 4dBsNk4Yj9z3VlV Michael Gmelin wrote on Date: Wed, 19 Nov 2025 16:25:20 UTC : > On Wed, 19 Nov 2025 16:14:27 +0000 > void wrote: > > > On Wed, Nov 19, 2025 at 03:14:28PM +0000, Minsoo Choo wrote: > > > > >Thanks for your effort! > > > > > >Since DESTDIR has been around for some time, I think the related > > >logic was accidentally removed while adopting pkgbase. This won't > > >take too much effort (just set DESTDIR to / if it is not specified), > > >and I don't need other information for now. > > > > I think I've found the reason for this > > in https://reviews.freebsd.org/D52879 which I didn't see before. > > > > There should be IMO a setting or a sysctl or something like > > pkgbase.enabled=0 though (my own perspective as a user) > > What is the procedure to run a custom kernel with pkgbase? Build and install a distinct kernel under a distinct name and have /boot/loader.conf set kernel="KNAME" (for example). That avoids updates messing each other up. Nothing says that you have to boot a kernel that pkgbase supplied. The old procedures work just fine for this, other than one issue: pkgbase uses /usr/src/ and usr/src/sys/ for its non-git source code directory trees. So, for git use, some other directory path should be used as the base for the git directory tree. Like the independent kernel, this independent directory tree avoids updates messing each other up as well. I'll note that for main and stable/15 , the pkgbase /usr/src/ and usr/src/sys/ need not match the same git commit --and the commit hashes involved are not published for reference that I know of. (But a kernel commit-hash prefix does show up in some uname output. There is no match to that for the world that I'm aware of.) > In the > last couple of years we needed stability patches (pf, zfs, etc.) on > almost every second release (at least temporarily, until an errata was > created). > > Would we need to run our own pkgbase server in this case or is there > another (non-hacky) way? === Mark Millard marklmi at yahoo.com From nobody Thu Nov 20 11:31:33 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 4dBx535jjmz6HFB2 for ; Thu, 20 Nov 2025 11:31:35 +0000 (UTC) (envelope-from des@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 4dBx534fHdz3mSv; Thu, 20 Nov 2025 11:31:35 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763638295; h=from:from: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=z8NrdQoNLmV1hkKvnzbtm5PwVzWee4K9fidqpk7hF8o=; b=j5zlR1X2UYHoidrgCR3reSyRvUqvQLOJUy9pY3Ik8yVGlLavNkFijmx47toej6Xy3Fqq5U qo6yUF787HTIR3vNxUpe3twerj62RMlraX5KhitCiJxO6U9xiHLfjEp8rfPXkVsJAQh34Z SEIKhrd54Z3UofjIJXFY1YwiQL+ux58ejsBxXhsfXLDrpQuGqYhpmFMV7F7e4GVwPaqHuL rSUL1yLOwZuguHEz5tngKm0eNLpoW5Xb34Ul5LG/DP9BpIHciBlCfZY9UBuI4MjCxVPx1R nhj2U8wyDkjskDLlNczgrUOqgC+7cSoMDSWK11mkWtzuexV19ceT6C9JNKlmaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763638295; h=from:from: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=z8NrdQoNLmV1hkKvnzbtm5PwVzWee4K9fidqpk7hF8o=; b=SCrll2aJ8FhJU7sp+n2Cq2hf/L5Ok8gNneu3VYYceUy2KMkr6y1GZqaoCV1SPu0rf7sTcX EZ0LcEg3JVi0zT9Xce3vpfvk0pRVCA10bCLRuOl0W0IvyykPZOvPyuNnH2MyIw/zidwchU 0W1vxYnBzteFrqLoBbyK3m2rDD6yF3iPirDsXmXuhB4ZZXQQI0psaDCQJY3EEh/E3y0YWq Gz8tHBEjiHAs6m8lpeNea4hxm3CdPy0XWxX4h1AxKDjs6rdDPJsgi+dvaUy4iECnBA4Vv6 xLciiC+Npn9eHo8ijWlfNTQIB1Sitwat5cfV75T77Y+0I3F06X+gEJCDm3fjCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763638295; a=rsa-sha256; cv=none; b=p/sqnWhkyRBvymJJnv7VPSMIb8iIQpP7v0S5/GA9wbzYwFcokH0YtvSw7Zde1NgRBIIXMg xEU9BdzcYVe4rUPRjIZ91nd+T76bHJNRun79iaNpb9gTDwIWJXBG3y+kskJpvt/DNvY9K+ 1unN6aOmqN4cEx9CmDIpV/yPRKEfeAjIe87qAVJhi6DoQqzUD9BcYe6+5einY9DaeA7883 92Aq91j8zQzKxqSLfAS1Q0Su0gNETfy0Eiy8UTxhc16J+raewfVTJQsw3935P0Tll9uLTa iXueppsZtXIURpuwPRSZIAwGolu8uSpayyBIEPkcpxfp2y5omFz8zC0nERU0kw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (lfbn-nan-1-698-103.w86-236.abo.wanadoo.fr [86.236.35.103]) (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 did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dBx533JBKzwN4; Thu, 20 Nov 2025 11:31:35 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 2AD37A6326; Thu, 20 Nov 2025 12:31:33 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Millard Cc: grembo@freebsd.org, FreeBSD Current Subject: Re: changing from pkgbase to regularbase In-Reply-To: (Mark Millard's message of "Thu, 20 Nov 2025 00:44:37 -0800") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 20 Nov 2025 12:31:33 +0100 Message-ID: <86tsypvt2i.fsf@ltc.des.dev> 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=utf-8 Content-Transfer-Encoding: quoted-printable Mark Millard writes: > Build and install a distinct kernel under a distinct name and > have /boot/loader.conf set kernel=3D"KNAME" (for example). That > avoids updates messing each other up. Nothing says that you > have to boot a kernel that pkgbase supplied. You're overthinking things. You don't have to install the pkgbase kernel packages at all. > pkgbase uses /usr/src/ and usr/src/sys/ for its non-git source > code directory trees. So, for git use, some other directory path > should be used as the base for the git directory tree. Like the > independent kernel, this independent directory tree avoids > updates messing each other up as well. You're overthinking again. You don't have to install the pkgbase source packages at all. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Nov 20 12:49:16 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 4dBypn4v8Pz6HLdS for ; Thu, 20 Nov 2025 12:49:21 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b6-smtp.messagingengine.com (fhigh-b6-smtp.messagingengine.com [202.12.124.157]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dBypm3R1Rz40sJ for ; Thu, 20 Nov 2025 12:49:20 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=nMiq4OPH; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=dbMoYTwt; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.157 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfhigh.stl.internal (Postfix) with ESMTP id CAA7E7A0110 for ; Thu, 20 Nov 2025 07:49:18 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Thu, 20 Nov 2025 07:49:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763642958; x=1763729358; bh=1VxN4WhGtj WOXz7NnP9X/NZuu/6nTYkvneuWk0IIon0=; b=nMiq4OPHxzHo74rpkdxSRHLC92 rQVZhHOpGG6UslzOVMAy7tpnWwxCB0WrX6Qtb/WE5WK9jzjCpXQh+Mp8dXUmwq13 jEDC0PgPqLrkZKCcSUdC/fWXW++sYZPA7KRHGvCtK1D4c09Qyk+E5mtPzE8t6Emd xy9yvPskfn+T53nVoV03uxLJAassQVB70JaoMumDln33rJq5kIKzQG0KNzfkmHTg GUsZ7u4A3GaLAZIYKjqUOv054fSGGbVHRiNunlxkpsylyajxPY1sJkHeiA61gwbO Pcw/LWerES5yikyNLZ5Zy2QCTMpQxmxGEyRh6GUMpjyFgWlDfjsbADI29eZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763642958; x=1763729358; bh=1VxN4WhGtjWOXz7NnP9X/NZuu/6nTYkvneu Wk0IIon0=; b=dbMoYTwtmwKievos1EqFhdzUKvzqEiuBKiJDu85STYGU8LJ5ttE 52E0KaD3IGqbv/E6cgZJhCzzbHLQA+03xPogQ2DC09ktQYWsxl0tHc4NKzar91Kl BcF8QYP4yBn+5E0jf/6jLyeIAt8wnCSCXhw3ln3fzmUDbPBTPap+MW1G89Hfr65E 5cZix+F2Ai2rO/NZO45fcpgfn6uyGtQ5P1HuvyKf1p5MUI1fK6A7eWLV6NZXCvQY UibUDgRNzL5dVq7V1IOPD4SzOlc65kNp2bCmFeAICY6Gkln+yQwrgBBKjPs0enzk uY150n+u/pIq9ndbrDO+3QTq9nL4VOJ+3GQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdejudduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepfefhtdevffefkedvvdeiueelgeduhefgkeelgfetkeetgeevudetgfejleekgf eknecuffhomhgrihhnpehtvghsthdrihhnnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtoh epuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhr vghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 20 Nov 2025 07:49:17 -0500 (EST) Date: Thu, 20 Nov 2025 12:49:16 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.85 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.75)[0.749]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.157:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dBypm3R1Rz40sJ On Wed, Nov 19, 2025 at 02:17:23PM +0000, void wrote: >My question is this: does this need to be done every time >from now on, or does some setting/tunable need to be >modified somewhere to properly un-pkgbase things? What I'm ultimately looking for, is a method of transforming a pkgbase system into a not-pkgbase one, that upgrades in the traditional source-based way. I cannot find instructions so far on how to do this. Maybe that's because it's so new? So far, when building the system, after initially installing kernel and world with DESTDIR=/ due to being prompted for it as mentioned earlier, on rebooting and repeating the process it no longer prompts for this. But I wonder if this is because I didn't clear out /usr/obj and update sources further and start afresh. This'll be the first test. In /usr/local/etc/pkg/repos/FreeBSD-base.conf I've set 'enabled: no' I notice that % pkg info | sort | grep FreeBSD- | wc -l 216 At what stage of the buildworld/installworld process or even after it can I remove all the Freebsd-* packages ? -- From nobody Thu Nov 20 14:32:33 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 4dC15x45QBz6HSwq for ; Thu, 20 Nov 2025 14:32:37 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com [202.12.124.158]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC15w3Z5Jz3Fpw for ; Thu, 20 Nov 2025 14:32:36 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=IbWgKMHj; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=i6N+1ip1; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.158 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 7ABB87A0172 for ; Thu, 20 Nov 2025 09:32:35 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 20 Nov 2025 09:32:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763649155; x=1763735555; bh=KDcmDmPSSZ RHjQhsis1zFzcTLtzRkc1OehXmTrePNP4=; b=IbWgKMHjevCCpghK0LyPNWFISZ xQ7UwpI4wXVhlZkOm4VD4anTpnjmtj3aoBTYoY4oZMKE75ac3KaPm9K4xzGwGK9t iXulJyNfvVsYSOGGBdHkP1Nq2tLPHchtL3jVr8fEjC4c9EY6R7TJFAd/piTzfl1Q 9i4HWrYDXHHLLkge/2wdnDMCDoXdRvJtwHp7YlLzKCqdZ57blGzD3MY3O0LKJ6Pr 4OLmNIw513Mxuow1Z5SmgQd/jFYwzCddZQt/zXVaTrmZFcfiA2UZbOnYR36qYHA7 9J5e/rf5V9LEALdgarsqyDZZJZgobxSq++BTdfyCZrf2GMNlfA4MtblqmX1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763649155; x=1763735555; bh=KDcmDmPSSZRHjQhsis1zFzcTLtzRkc1OehX mTrePNP4=; b=i6N+1ip15X+av5YJL0thJCzcUB6v1Y6qiGdoeUsZQiD8KrOcxn8 Gc4yTEMlN4OvbQxSNeagmYZxkP/dVnKtQ8W9+bfnhC9TB9g9aO56hHI3uWIE/+7U vXSUyVsawsPrP2jp87TQzbCUwlX7fQVJUlxQeBwEbLJQNGM8jcyBcxHiY7qpQq0C WlJYACJIdNKHAfcz96Q2tH0iWFCV4psp4V2LBQBqga2lGG0Eu9TjdyFW7hefK1NN v3qkOsLujGIFxgiRO0Sfmqd+JiHX+0E9JP96inQXhpB8YAGBC1yTD5PelIQ9Lcjh PM5wUj3z4skf+EkSoxelhg44QZskrWIK5yw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdejfeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgf eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 20 Nov 2025 09:32:34 -0500 (EST) Date: Thu, 20 Nov 2025 14:32:33 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.83 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; NEURAL_HAM_SHORT(-0.23)[-0.234]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.158:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dC15w3Z5Jz3Fpw On Thu, Nov 20, 2025 at 12:49:16PM +0000, void wrote: >So far, when building the system, after initially installing kernel >and world with DESTDIR=/ due to being prompted for it >as mentioned earlier, on rebooting and repeating the process >it no longer prompts for this. If the old obj tree is deleted, make cleanworld dir clean is run and then make kernel, the prompt reappears. So the behaviour of a regular installation has not been restored by the steps so far taken. What can I do to resolve this? -- From nobody Thu Nov 20 14:55:44 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 4dC1d00cJpz6HVkC for ; Thu, 20 Nov 2025 14:56:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4dC1cz4HfQz3Jkj for ; Thu, 20 Nov 2025 14:56:03 +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=1763650556; bh=6NPFjH5/SQWJU9T9XleW5dsrrsC1urk61tL22GY8Iw0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZmaoB8TCmBQrbzL10W7Za3iFBhzYD2v6sJCkjyEX2x5XEPtMqMHQGjuYgOt6LcDZyVyCfn9AzNNQ5YCrIgM7i1f33h4QNmj6pUkJHxNdGCJh/koZxjCumuVkML6tj3D3YyZCq92jaDyky/6qB9D6vOMeaLqAqgti+FjtLyQppo/99rgs3vqNogG6loh883WSEnO88N0XOIxZ1V3NUiL2cYT70MRQcr+9HzWvTXfAq9chr+felqIFY4QG+zsJUDP4xCdYAnBYv60K46JmaCRPli6zxp29rlpqHM1UNqLA2xMbC3zjbcHC3RKjPpWGFG5OPiTaMCux7CMHsqaha/tooQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763650556; bh=IWlA4ubxEJYWWt81GTqUhJLvkf0x6zuPP4qgBiGPv3G=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kp0CGzhT72tNB4BoieTuTBsY8PSrxPeJZH4qyTept3zGhrh5BWk5q9RTnpIdw4pd8eErl8PjuNR87m5exrlInMXteS7mBNUOxhj0evWZGPOQ4My6rkYM4hYSTJ7AIhKjnymNLKw0GEKV2/x2rz/6WWQnZTOTY5mirDUlDJxoZRexLZvkeZ1FWRsUX3naETgv5ifM26VNirAk8WE18leYy/yUVscpQ4DalnkQZqOUYbkKK2cEcc3UY7Uyz3bdMdIm7ZubvJJ5hwmPKZcoo08pHh57i9Ld3sWwPg9WNMyphTakao0nx1MTPscyzQql2bQLw3Vp5TYULLENJOYQ2CYgHA== X-YMail-OSG: taHmWkEVM1k1cmWX4JJzPHregPsR1CzjHgnMaB6r_EGSm31Ute6GVTCvkztXubP 5DuBC1gWyiHbU9mosc_cKvJViBaOy8YTOH9G0k7vk21XIAE.SI0.AmmZ2TYyQZNl6KqGDg3V.beV CheDv1t.cQLXoNeniIbnh8m5fz0TZ3ofGEPgdSufVjw1F7oG_cdMStofiqz4PmAFoytTybSKNlU8 Ik_0I2fPR7r55CAQ63lD4Gg4CNJtnzxlgwzE2aAJ8xT3bVLhej2RUcE6qH2af21r9xL5OEOs2RXF FKOfFUSXb24RyMtDZqiB1AvR2EGXkywEHkDAHHE50Wd8MrDU8vcjH.1hplcMBJRk1ml9FcjyCYvb VvrMQCX7xDZsc_5CMvwL2S.IMPo0EzCdTjXfylgiDoOii2ut3VUAYk_W4FUTnqDDiW8l7P1YrsBL kKx86_dGtiOr8pCFonNXrowsukOYdSLQKYKARRMMYfocfhoqxM.REtteW_AruzVT.trzE.gNaXZP GYQOFCwCXlHxPSndSQRktIl1jOnq.gRSCQbS6iDKo2PvLVfonTpHD2NXj9Z7f2WGLfK88tqqvp9s GBPDMiVsk96MlqMz76SeTruOPK5dE.RQeCo9HmEAE1IDnWuALnbzCieGAVwkD5U6Qtq6UThgzD81 MLJd7.idn.Nj17pV23WVjqwr0aL7pmJIeWxNaiBViWqtdkRTg.gsQLASqofSRat8Gyq7PLLl7Sej HiLwf3uj_OmvNQ0VnYaK.AVJ33BN82JeEFDoQoIsgMwQhed8RkqUg3ddmzJSeeD255PSn9cvF7uK xjq1EE0VByKP1rkV4gx4fQcrz0ODsQOPELPsiDOJkFQ7X65hgJkgk8hVCXNzCRsn.P.hqONHAGR5 a5CXcackGNMFYKPssE7oT.kPABwueQWAu0nOzRfKWia7kHPxQdMTBfFzWBWf6xx1qqCNRA8FGESz RXVh1NtlP.SNhS2Wr76Iw9z5jIxAQZc93kWnPen0XCvPMtdqTdhCp99O52DjRjhyd.0FoziJ5Pho byezYCUgzQVOpA_DnVfZ1CeTyJ8CLaktNPr5jCwJlt3SMvedD9LBCPYqkwEhQ9LZI2SX.zkxk5xN fx8HKOmtFAXOte92mpOiisyYY0T124tvE4qcXPKBQSNsG1uxFfUSbKo.8FvYgLGPpIhC44HzzwY6 w13lZxNgZsPWiAeHtxjKcgZKkJ22auyxnsxbjgyDGuNkaq4dd153xTNPoVJ8tMonPKECcYmewCQt w4Skymzn2of_2cw8ruD6YpslJNl4MOztNRz8fJEUBpMM5wLU0pdgE4Vuc.yIeivRkKWMUY06Xuwx afq_1OmFUfggjcKcjTQXSwdubCNb8iUSYen5nDtZ4lZWYknwQaLeGUxWIih98pfO7kR44Vv0edC_ 2aqU3SNO9coySyUwqLHhrDLs5lUnnKy0mqSYI25Femf92ZR4UXlK4pFZCUe9v_M9VYQFNzgocDc3 9NkblO6ZdOVNi2WOCvAdbw2dghoIpkgcOgwQqYp4KFlx3OpkP99mtZNQoyHXlfHmqLLCZvKb6FQx P41s0md6l4jL63OzcZgOdslOi0hsnIbvNIb5E4kfApzMq46R7Sp2JTjtUlZyxK0A9e7lEC16wPho 6xsxfjIxe4LgpMfHvUh.6b_bvQc2tlBNGplhu.Pgdx9L52zF0DpHJIy6Six0UXQSULx984c04DB8 GSWupLJs2A0gI39oyvbEoUUeiVF6gi5ndRLyouocIF5sS1QUmzQ..Oi8iROpla6ith58SBxGt8Mt 5Dy2p36gSioCfwNDBsRHkdjLrqDCNwvVpodJ5IrNc5PGko.B.2LTynvw2b5LRav9GffD4i7UH5C_ uMj_xeFX2L9U_2vCHJ9vbP0Um1TmYF1YqeTPi0PxcYrLQNbzTyloEXUqL4TnvWbULI1oLIMUr23U .FwSiLXBZKjJw88sw4Xs6xd2PvzMvwU1DK9Oat9ZKyBid.l_Vfg3TnSfiesbBGCnr310yB4wur.N W7FiEVHtXpo4wZYoHTp4LOk.b6ND342q4A93jpQ57x9g9YMLmZcmGaVLAn9PEIml22aF7MIiT6T1 rpSbUY_DjYMTpnyH.ay.FU2En4dHjyO4lDds_Gh7uQ2ZtcofKOS4mQ75KBkzbTds2Oee0jINuzf4 dQ8HzRiTWWgJB7czQ70LQuYiREH_zr1lzWdKKzKsP0OVp_O_MXz3q5j3oIWVPdG1p8YhXeyh4TIh MVFC87.pwCtTgOziNDV6LB9ne2rrITwVSCyEzFIpS0_x_I88sbwpc3hIPO8t3IEVsz8x23F3EFhU J X-Sonic-MF: X-Sonic-ID: 4845a576-47bd-47f2-a6f2-7a8147ced1c7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Nov 2025 14:55:56 +0000 Received: by hermes--production-gq1-869cc4b577-bvsd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 566fec8d38c43d7aed12750beb2c54fb; Thu, 20 Nov 2025 14:55:55 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: changing from pkgbase to regularbase From: Mark Millard In-Reply-To: <86tsypvt2i.fsf@ltc.des.dev> Date: Thu, 20 Nov 2025 06:55:44 -0800 Cc: grembo@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <86tsypvt2i.fsf@ltc.des.dev> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= 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: 4dC1cz4HfQz3Jkj On Nov 20, 2025, at 03:31, Dag-Erling Sm=C3=B8rgrav = wrote: > Mark Millard writes: >> Build and install a distinct kernel under a distinct name and >> have /boot/loader.conf set kernel=3D"KNAME" (for example). That >> avoids updates messing each other up. Nothing says that you >> have to boot a kernel that pkgbase supplied. >=20 > You're overthinking things. You don't have to install the pkgbase > kernel packages at all. >=20 >> pkgbase uses /usr/src/ and usr/src/sys/ for its non-git source >> code directory trees. So, for git use, some other directory path >> should be used as the base for the git directory tree. Like the >> independent kernel, this independent directory tree avoids >> updates messing each other up as well. >=20 > You're overthinking again. You don't have to install the pkgbase = source > packages at all. >=20 Your notes would apply if Michael Gmelin indicated never wanting to use the pkgbase kernels. But I took the following wording to indicate otherwise could be the case sometimes: QUOTE from = https://lists.freebsd.org/archives/freebsd-current/2025-November/009406.ht= ml In the last couple of years we needed stability patches (pf, zfs, etc.) on almost every second release (at least temporarily, until an errata was created). END QUOTE That sounds to me like they use up upstream until they discover they should not and they later try updates and go back to using upstream when they find that it works. For the testing of new upstreams, the working kernel might be kept around for a time to potentially revert to. I tailored my wording to that context, right or wrong. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Nov 20 14:56:46 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 4dC1dt2D1Lz6HVkK for ; Thu, 20 Nov 2025 14:56:50 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dC1dt1Ysrz3Jpn for ; Thu, 20 Nov 2025 14:56:50 +0000 (UTC) (envelope-from matthew@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763650610; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nzy67BJQjWFCFyw7rEBknpqudRUsxY9NThyj2voDipw=; b=jvVnbXhgOPobJFCFrnQiocZOceIKx7I/+ND69umGslk0iRfFyCmF1ieBBZwkNKJiYeEp2t Qnc8yNqahF010JRU61b0plgxdvrnowmAqSRsW/7hmBR7LgL836vkKMfjmM9vzdMZ/skRqk JGqyH2TSzN1VFFDXnf3OsaT1PftTpR6rBVF0Bf0VWpC/cmlVLSkBnUeE+jSU2PNbiuPRwQ Yn2VGjDVcETlQoUb6B+GAdbL+Jb1B1X8u3Zwo6ArYA6ZBBIIMJ7YEbXcjG4YWc51lHAbL5 tg+zmYCRWQ6uWIq0rGMh7i2N49+/qjEQLy8EOK0Qh+ZsDKCDI5b66lC4ktMFHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763650610; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nzy67BJQjWFCFyw7rEBknpqudRUsxY9NThyj2voDipw=; b=lhhWFADqmAdTydupNqFwM2qD0Snl2NWo1fsKaEb2x+J4L+igpdtCxobUsDVJzX0qD/HUif 3rdstCN6aY+OMzaHwVrZidHbyIqRXvfdEA5Src3mqyd/lqQuKm7M3r40ZFouYX8OH9SXIj bhbtrrY3VR0B4fB45mwja38ylQLRQZsOD6llOSY9HciVGMycBYgAzIkCfMI+lLNcoTIElp Q36vc4hnNL9dy9tdfmhD1Il/5nKhwVTcwwGMmw4axCp/0vSsmPUBIZqVjZkq9Bz5MozT3g yqLxxljVxxjYbOZG+ZBaxmGKj9QDeJtCipLYDtYLCiwgTfodaZxnCR5sClsMaA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763650610; a=rsa-sha256; cv=none; b=huLNQp0KP1lrMHSAvpV2nugLoJ6/XBSzO9HntvWHswT6LM+2Ol3bHz0lKujHkrLcZmKUxG 5Eo+GeLD+L4XeqN+sOXpwnrzre0xToQlP38n/Ccv/g4GL0SiOFgy0bZutDQudCJXSGnMl4 qS1G2hyXfT+lN+vua1eJ/BwJrdq0IDFCIz+tduzLPFHCR5PWXIn/Ez0L+rNvr0xYTuCnpG 1HlYN1iiL8PcwX7ah8UGmjmCrgQ4ZUwXq7DZ9MfOn8P1ClXtOUSgmhgXmE2IFrcqRGrr70 bJhf11K7MXuBLyOQKRQ7l5zkbhoFeyTy99gEo8R8p3sVPtUVNSdPlfP0bzmhYw== ARC-Authentication-Results: i=1; smtp.infracaninophile.co.uk; dmarc=fail (p=none dis=none) header.from=FreeBSD.org Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (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 did not present a certificate) (Authenticated sender: matthew/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dC1dt0FFGzyc0 for ; Thu, 20 Nov 2025 14:56:50 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from [IPV6:2001:8b0:151:1:1815:9f0d:ffcd:f5b8] (unknown [IPv6:2001:8b0:151:1:1815:9f0d:ffcd:f5b8]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 083AC469 for ; Thu, 20 Nov 2025 14:56:47 +0000 (GMT) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=fail (p=none dis=none) header.from=FreeBSD.org Message-ID: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> Date: Thu, 20 Nov 2025 14:56:46 +0000 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 Subject: Re: changing from pkgbase to regularbase To: freebsd-current@freebsd.org References: Content-Language: en-GB From: Matthew Seaman In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 20/11/2025 12:49, void wrote: > What I'm ultimately looking for, is a method of transforming > a pkgbase system into a not-pkgbase one, that upgrades > in the traditional source-based way. This is how I would do it: 0) Make sure all packages are up-to-date and any no-longer required automatic packages have been removed. # pkg upgrade # pkg autoremove -y 1) Make a list of all the packages you have installed that aren't FreeBSD base packages. You can exclude anything automatically installed as a dependency of anything else: % pkg query -e '%a = 0' '%n' | grep -v ^FreeBSD > packages.list 2) Move aside the pkg database in /var/db/pkg # mv /var/db/pkg /var/db/pkg.old 3) Re-install pkg(8) using pkg(7) # pkg bootstrap -f 4) Re-install all of the non-base packages from step (1) # xargs pkg install < packages.list Untried, so may need refinement, but that's the gist of it. You do end up having to overwrite all previously installed non-base software with an identical copy of itself. The only other alternative would be directly modifying the pkg sqlite database, but that's not something I can easily describe how to do. However, this does seems like a retrograde step to me. It is possible to build your own packages from the source tree, and then update your system from those, which gives you pretty much the benefits of both worlds: # cd /usr/src # git pull # make buildworld buildkernel packages # cat < /usr/local/etc/pkg/repos/FreeBSD-base.conf FreeBSD-base: { url: file:///usr/obj/usr/src/repo enabled: yes priotiry: 1 } EOF # pkg upgrade Again, untested and you'll probably have to flesh this sequence of commands out a bit and work on the details, but that should give an idea of how it would work. Cheers, Matthew From nobody Thu Nov 20 15:15:16 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 4dC23N6HFHz6HWxc for ; Thu, 20 Nov 2025 15:15:28 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-24429.protonmail.ch (mail-24429.protonmail.ch [109.224.244.29]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC23M6zF1z3MGd for ; Thu, 20 Nov 2025 15:15:27 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1763651723; x=1763910923; bh=SFeHQIcLnWEkQsrW9LVxuzkSEnAnizhPL17bWwRcmWI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=UegVmMvyKCV+POlo8JwsFq3kbEkSHk+MO5DNJsILqmvD2rLd4qge+7fOyes1cA4fQ iuZj6G6//OecikXkzqZEzizVKfNDceRyi/xDspDrT9AgX7ECCzIlwaPVHWUPBcOKBN TWmTKsV+nwtN3wGZ7hpsWgVTlx71cpQq1iH28l8nFDGKxXpLAZs/ctgmbctRdy3U/O cFrUdzxP+XXnOkPfnKsHYl3Y9s0lfcH3a0dKv2vBgyPxVCAAQz5DoJUZI3mJ5CV0jL /BVSfXa4Qy8vztItW8KhHT/hMv0vuwiCnyqznCbGhojdigTM6IkDh5DQohUNwJqGZR 5VCBXUWtNJMyg== Date: Thu, 20 Nov 2025 15:15:16 +0000 To: Minsoo Choo From: Minsoo Choo Cc: cyric@mm.st, freebsd-current@freebsd.org Subject: Re: nvme.c:2012:2: error: call to undeclared function 'memmove' Message-ID: In-Reply-To: References: <814ce2bc-2a95-444b-9ab7-7e680a024c68@gmail.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 120877f3b0dd6875963a19b41fd9eac6384b4907 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:109.224.244.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dC23M6zF1z3MGd On Thursday, November 20th, 2025 at 12:09 AM, Minsoo Choo wrote: > On Wednesday, November 19th, 2025 at 11:52 PM, cyric@mm.st cyric@mm.st wr= ote: >=20 > > Ian FREISLICH wrote: > >=20 > > > My kernel build started failing recently with the following error. I = use > > > a custom kernel config but looking at NOTES, it's not clear that I've > > > missed an option that would make it compile. > > >=20 > > > In file included from /usr/src/sys/dev/nvme/nvme_util.c:34: > > > /usr/src/sys/dev/nvme/nvme.h:2012:2: error: call to undeclared functi= on > > > 'memmove'; ISO C99 and later do not support implicit function > > > declarations [-Werror,-Wimplicit-function-declaration] > > > 2012 | memmove(sn, cdata->sn, NVME_SERIAL_NUMBER_LENGTH); > > > | ^ > > > 1 error generated. > > > *** Error code 1 > > >=20 > > > I've also tried compiling after blowing away usr/obj. > >=20 > > It seems to be the following commit: > >=20 > > https://cgit.freebsd.org/src/commit/?id=3D8d2a50bb38051fefeb1427fdbfd24= 9f2829310d8 > >=20 > > And it was reported: > >=20 > > https://lists.freebsd.org/archives/dev-commits-src-main/2025-November/0= 37599.html >=20 >=20 > Thanks for figuring this out. I will see if adding #include = solves this issue and try to create pr by tomorrow. PR created: https://github.com/freebsd/freebsd-src/pull/1893 From nobody Thu Nov 20 15:51:33 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 4dC2sB5rkMz6HZCR for ; Thu, 20 Nov 2025 15:51:42 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC2sB15RLz3SGZ for ; Thu, 20 Nov 2025 15:51:42 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=LvrqmoQl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of henry.vogt@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=henry.vogt@gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-64074f01a6eso1802648a12.2 for ; Thu, 20 Nov 2025 07:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763653895; x=1764258695; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:references:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=6gZvmUtwW1wUeLCpgQ020uawmcmOu3ElJJe5+LWy74k=; b=LvrqmoQl/SdviCzronesS6zjJIUotyKWk+UCNUFwEm/gh49IvaL6Ire8W12/JLnJ8U jzbgrNclGvi/JGUmKqX51CMA6bmCBu/wHfJ3jZKzZQc8r5w90YmOeGfFYdGyC372mWb3 8K4+C6lvohF2nLIh6WDwk0rKi5yTsLTI5P4/it6WHpnUNCpiHRQKCwucJJqJGMs9I1Pq V01As3qSlpYgDbimr8ncGmBr1o4MuNmMopuLnkCAqSEjIWm1CF9JM1QmPXYxePswUN6b ViDY9t+vMUGRGVv1ZQi3ro5sew6BOqCV7CViWVUjsuR8aH/1uEfk7Tt6+HJRD2m7rWRa +xNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763653895; x=1764258695; h=content-transfer-encoding:in-reply-to:from:references:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6gZvmUtwW1wUeLCpgQ020uawmcmOu3ElJJe5+LWy74k=; b=GiVJcMazwhHyCLbKiQ6k01+42Y6JVfNVR9voUyEjD0/JdR6Ezbs5EkyNd0i2rmcl4f O7cUg7cYi2eOW6yewOMs2jVRtN9C7WhVJX5kovcU4abGKkrffmpaFRw2bEXZMHtxy3hr I0yTom0YV0f+2Ba3Q2B7zp+/QiyMJjeRboeQ6oiOHBm9Ixjd5dYOgzygEmuIWYqBnRW1 iVO78Xd6D7sIm+TvNXT3vjczSk6BO36grc3KRsHVF07APZHh3WBCmyhGpxGYV3FqLLy+ 5c+Jw30ZrfKneBSw8Zn/F1kTj585XAzk/OrStNCjJ4u1/R+Q50cIUpc7/0psGa8T3wUk 7oIw== X-Gm-Message-State: AOJu0Yzr2VBsCT4mws52u7QNSo14Z2nwHPxmW7z5Dyat8TcflvyGTKkg HM5WXT8iLzW4D3Zt9EAMeGq20x3LRHkOkVfLikAzHrarX3z34K3yEtr0GWPklA== X-Gm-Gg: ASbGncuq63fw8rdlOxhzD5r7K1dsGFQSwvCnKXORlEUlQ7paAIYIvOLfNuLIUEaFD5v AZR9+8FmM9X+3R9kwz+vIA0qN46WPMIW8XKZ4+rni4p8ACpwmIQm3kCd3qBUyWMN3quQRoeb2Lp NKAYCxZ1zWwqhre8uuX2uORbYVHPOj7JRG3QwBEkHsiePikOCPkeQQv3lxSESzajP2YE7OaG7T1 6nAIdPbIa3rtu7CWv7sbXM6AdEcTch0lnTc9s8BhfPZuYRaQOUAxUxQXgYONctyWVdO4J+66uUH bBrgScurUbVxifXKiwbafBp7ssVkj7drCf4GeOX90JoEkCkJ92yZhDkvJJPUutDCHsONCLmXqOQ 3o6E24myj2e7v/ctwaF7IyJzpyh9L7jOwyW0AzVsLygJEgx02AFVLMjiVrhu6X4s3f5Ps0ud7JS RtOnOKhSb1VAGVp4bb2RDiquIgqPQfTK2ueSrU3J1iDRkLjbL8IICzntf9Jo71 X-Google-Smtp-Source: AGHT+IHcn6zwUnH/SB8y5wyjjzOWP39BPSzuI4HwQwt/yq38IfWyDeoFELTVW0ScdVBbf4SbBV1G0w== X-Received: by 2002:a05:6402:13d4:b0:640:9eb3:3673 with SMTP id 4fb4d7f45d1cf-645363c6b27mr3474855a12.4.1763653895421; Thu, 20 Nov 2025 07:51:35 -0800 (PST) Received: from [192.168.2.224] (pd9f1fa99.dip0.t-ipconnect.de. [217.241.250.153]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6453642d3ecsm2319279a12.17.2025.11.20.07.51.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Nov 2025 07:51:35 -0800 (PST) Message-ID: <0d4efe48-34e1-4c0e-bbf3-07f2675f923a@gmail.com> Date: Thu, 20 Nov 2025 16:51:33 +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 Subject: Re: changing from pkgbase to regularbase To: freebsd-current@freebsd.org References: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> From: h v In-Reply-To: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from] X-Rspamd-Queue-Id: 4dC2sB15RLz3SGZ Am 20.11.25 um 15:56 schrieb Matthew Seaman: > On 20/11/2025 12:49, void wrote: >> What I'm ultimately looking for, is a method of transforming >> a pkgbase system into a not-pkgbase one, that upgrades >> in the traditional source-based way. > > This is how I would do it: > ... if on zroot, you could simply: 1)create a new bootenv e.g bectl create NONPKGBASE 2)mount it e.g. bectl mount NONPKGBASE /mnt 3) pkg -r /mnt delete -f -g 'FreeBSD-*'   # this is  one of the rare legitimate use cases for  -f  imho:-) 4) install the base os as usual  e.g cd /usr/src ; make install DESTDIR=/mnt 5) activate NONPKGBASE  snd reboot into it. 6) if all went well destroy the original and voilá Hope this helps. From nobody Thu Nov 20 16:27:30 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 4dC3fh5nb7z6HcPv for ; Thu, 20 Nov 2025 16:27:40 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC3fh0cSyz3W6p for ; Thu, 20 Nov 2025 16:27:40 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=je2m6hyW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of henry.vogt@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=henry.vogt@gmail.com Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-6419b7b4b80so1493280a12.2 for ; Thu, 20 Nov 2025 08:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763656053; x=1764260853; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:references:to:subject:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=5NMJQnxN5offJF6B3/t6UGkQTv256AcDAW5/lsxlHFI=; b=je2m6hyWdheYqzaewxPJf1trGcBMYDEOBRb7xT2YSkcAdeDYlORU3FJslLDEE0MKL4 kVd4vqVdKQIJtY4oWaGejfhbagb6RDUHW6rp5P1oOedrSegxtR6A8L2+HHV8/8G4xlSN VfMvLfhutqkq3hwzEblvLP9B0aYNz1p6SpvUkUAsf6dMPPf9W7dv0mcwwTilZvKuNC4L iog39lXxRUV/PLIBVaAujV7iFGyyGiB7ZssXU/zFSBtzE5vyCltiZJbLJ96kE4TqT5MC EnvZXn2T4oQMcKYxHeC3kbiupvsxarzJWTGLZY2PRT2DZgdVBF9qzQf4MDrHRdqdb0tq jo4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763656053; x=1764260853; h=content-transfer-encoding:in-reply-to:references:to:subject:from :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5NMJQnxN5offJF6B3/t6UGkQTv256AcDAW5/lsxlHFI=; b=kBr8g/FTq7r+9RkKhtFSHYThRPKk7MTqOlAzxerkVxTV9gPJFFT0uCdRjB9KhY8yj0 SUcTyZQGk0+oiY4KIRuOYhLvv5wLLE+MrUN08favfZ47BPkJIYsvepYGwtrl4cahyrak Wx39xFFQtVjBf/+Ue48dOcTgBsOsRr4i2S5N72nA1k2nc2Tnknl23CeuGRQMj+p76FcK Ct5pHb7gzH6gkTHSCDZuuyczvkOlvaT7clu61sEfiHh+71C27rGvnxg5o36RxXZlod85 rSTgzSw1Mj2S/1opAqd1L1uMt2TaCqnZjRmBGbiwr1kRZc94FJCEqko+5cYCj/yiDWWq kFpw== X-Gm-Message-State: AOJu0Yz2MklQarPw14tOYpGi2S1kftELV5PCgaTo8Zp8RYZdfkxYA7vF XA7zSboPf1EFnxxvWZoLKOeI1GIavcQzWq27YOiNENVr3rL8rL3UEVuTV9zkEg== X-Gm-Gg: ASbGncsR9OZFVHVQJk64fvck6vPVM2dKgM0ZYzZHvuQXGDHPszUcRsG00epOXmlZK3n zaVizHH/MwPoVXFydMegj0laBN0wADG5rSgxEMPDiceq/j+rohVJtic64kdJS3oFvMRZEtU85vq xSPx8BGcBgMb7YPgJUonoisDmP3uEUiI0IfP341OG7DKAw3gF7T/5SVdi4kHOBUORcJUxyCLNhK 4pwV3LsGUM+pTSspvbH3OdoEu8a+jGdYrFtjoDSNV4IRiPvu9Txu9nxyxAHx+j5qwGPEgG5lebr 0qFP0E164gPQzyHbWI7vQjtwAs5j7FJT9v4CJTAvhIoy8BdooXYP5lETiC/UkskvVupFRo7JrK/ 27g+JNTsLY+eDakSnbzT065jXpAmMDiHRGGj2YBXTPeE0K1+R2UbdH5bqnOqixMzuch0VfOhEsZ 6wwM2dvvN/1lBVH5VyYKe8ULmA59LFx4s8EYIZURG/CHSm2lakVQQTnNGadS0= X-Google-Smtp-Source: AGHT+IGzEwg5HtIiGsgeAHiuHws/vk+zb8S1cvh+7VoFQA8Dgiq1aD1q8DA8R23dA468A86IHBLTeQ== X-Received: by 2002:a17:907:3f9e:b0:b73:76c5:8f7c with SMTP id a640c23a62f3a-b766ac29042mr10367466b.43.1763656052538; Thu, 20 Nov 2025 08:27:32 -0800 (PST) Received: from [192.168.2.224] (pd9f1fa99.dip0.t-ipconnect.de. [217.241.250.153]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b7654fd4e6bsm239182066b.34.2025.11.20.08.27.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Nov 2025 08:27:32 -0800 (PST) Message-ID: <06f1226f-f904-4bd8-869c-fb236d7fd73b@gmail.com> Date: Thu, 20 Nov 2025 17:27:30 +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 From: h v Subject: Re: changing from pkgbase to regularbase - small addition in step 4) To: freebsd-current@freebsd.org References: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> In-Reply-To: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from] X-Rspamd-Queue-Id: 4dC3fh0cSyz3W6p Hello, Am 20.11.25 um 15:56 schrieb Matthew Seaman: > On 20/11/2025 12:49, void wrote: >> What I'm ultimately looking for, is a method of transforming >> a pkgbase system into a not-pkgbase one, that upgrades >> in the traditional source-based way. > > This is how I would do it: > ... if on zroot, you could simply: 1) create a new bootenv e.g bectl create NONPKGBASE 2) mount it e.g. bectl mount NONPKGBASE /mnt 3) pkg -r /mnt delete -f -g 'FreeBSD-*'   # this is  one of the rare legitimate use cases for  -f  imho:-) 4) install the base os as usual  e.g 'cd /usr/src ; make install DESTDIR=/mnt', afterwards     'rsync -av /etc/ /mnt/etc/ ' to restore the original /etc 5) activate NONPKGBASE  snd reboot into it. 6) if all went well destroy the original and voilá. Hope this helps. From nobody Thu Nov 20 16:58:45 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 4dC4Lf2tQWz6HfVm for ; Thu, 20 Nov 2025 16:58:50 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC4Ld2mntz3ZZX for ; Thu, 20 Nov 2025 16:58:49 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=GEWchdNn; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=AuXyS53S; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.151 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id 092221D0015C for ; Thu, 20 Nov 2025 11:58:48 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Thu, 20 Nov 2025 11:58:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763657927; x=1763744327; bh=KHR0KThf4a nQtoNt9DCPWTTmOmY9oVjRuHDTGBmXJ3c=; b=GEWchdNn+8aWVLRdG+59Jo3Ms6 3nr7+14w7ELCUrHOxeoOSQo/Iglqg2YlicTyRwG3HyEnzGxrvqBezPg2j3G6H31e iF0MH0uvQikkQiaf7rHaeqHY/V3eujddH/Rh+E1P716v449BdaWbFwqTgPl3L1vu bw0Fwv/fNi4cyhIdrsjMYgQ/eXn01BkHYUJR+Uj4FKMa1D7ZVc6f1niKfOwuUWFo Mhoql3HWdYJixhmCH5+IKnjmFAb/Ov/jsdVtvxEI4Cd+ULl4YLUTF8/LsjyOa41t 3So14jJ0IahBblyC4jJbORs6ihCIPadd/EfF/pMH0oycv5U8MNs5dkUr+Biw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763657927; x=1763744327; bh=KHR0KThf4anQtoNt9DCPWTTmOmY9oVjRuHD TGBmXJ3c=; b=AuXyS53SWh8njzvw7WckXJEGH+2gjX1ofpuLvszacGJsiOt6H37 0T41knZR/5Ir2N3ofNUzqZC2U6GGjD4fXaeT0oNmT2IZFzyx6gHjjuO4I1u++qiN 9wn+6HXShd++ynd4uPfwBGQpe3kRsNn0qI8zWBg4va0ufmGa8btutRx+gvCh1PmZ 2PRAuMnUKHx33kkxUD2HcJafTJjbVasOdxIIp5sOt3EjzeK5i1hB7k1b4o+cMYd0 e4JleD8o5kNVDiHdPcfiI/a5J/78FgwlUASy7YbJMvr9t2ZKKm8RmgkQEqrblUM0 wwa/dHr482Mv8O9QCR3qUVJDQ6/hPK7AnqQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdejiedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgf eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 20 Nov 2025 11:58:47 -0500 (EST) Date: Thu, 20 Nov 2025 16:58:45 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase - small addition in step 4) Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> <06f1226f-f904-4bd8-869c-fb236d7fd73b@gmail.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; format=flowed Content-Disposition: inline In-Reply-To: <06f1226f-f904-4bd8-869c-fb236d7fd73b@gmail.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.59 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.151:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dC4Ld2mntz3ZZX On Thu, Nov 20, 2025 at 05:27:30PM +0100, h v wrote: > >if on zroot, you could simply: Hi, sorry this is on UFS -- From nobody Thu Nov 20 17:17:06 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 4dC4lx2vdyz6Hggv for ; Thu, 20 Nov 2025 17:17:17 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo49.interia.pl (smtpo49.interia.pl [217.74.67.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC4lv5fYgz3fsF for ; Thu, 20 Nov 2025 17:17:15 +0000 (UTC) (envelope-from vermaden@interia.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=interia.pl header.s=biztos header.b=t69rjIHy; dmarc=pass (policy=quarantine) header.from=interia.pl; spf=pass (mx1.freebsd.org: domain of vermaden@interia.pl designates 217.74.67.49 as permitted sender) smtp.mailfrom=vermaden@interia.pl Received: from [10.0.0.33] (unknown [45.148.42.9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by poczta.interia.pl (INTERIA.PL) with ESMTPSA; Thu, 20 Nov 2025 18:17:07 +0100 (CET) SavedFromEmail: vermaden@interia.pl Date: Thu, 20 Nov 2025 18:17:06 +0100 Subject: Re: changing from pkgbase to regularbase - small addition in step 4) Importance: normal From: vermaden To: void , freebsd-current@freebsd.org 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: multipart/alternative; boundary="--_com.samsung.android.email_1437749042660370" X-IPL-Priority-Group: 0-0 Message-Id: <20251120171708.2A2B8A002606@poczta.interia.pl> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1763659028; bh=UGpltZcGUKevtx+B8oZ2yq8iTpZE8yXZNa49C0yAjJs=; h=Date:Subject:From:To:MIME-Version:Content-Type:Message-Id; b=t69rjIHyoS8gAPTvbJlLNp7yxb/kgPUgOaoiLsYA+bkbaLPKmjARSJZmCGMTLa/wW mqXgXT29zVcgWHPvH3c6gxpLbkdtcV9Sebdl45uiw6WPSv9Kt2vJvSX8bcDy2iH7S3 SHbJxYUIE9zguw4UK6kXoiKYSlxkoAlHs7Qr1aPo= X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.53 / 15.00]; MIME_BASE64_TEXT_BOGUS(1.00)[]; FAKE_REPLY(1.00)[]; DWL_DNSWL_LOW(-1.00)[interia.pl:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.73)[-0.728]; DMARC_POLICY_ALLOW(-0.50)[interia.pl,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:217.74.64.0/22]; R_DKIM_ALLOW(-0.20)[interia.pl:s=biztos]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; RWL_MAILSPIKE_GOOD(-0.10)[217.74.67.49:from]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[f-m.fm,freebsd.org]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[interia.pl:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[interia.pl]; FREEMAIL_ENVFROM(0.00)[interia.pl] X-Rspamd-Queue-Id: 4dC4lv5fYgz3fsF ----_com.samsung.android.email_1437749042660370 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WW91IGNhbiB1c2UgVUZTIEJvb3QgRW52aXJvbm1lbnRzIGZvciB0aGF0Oi0gaHR0cHM6Ly92ZXJt YWRlbi53b3JkcHJlc3MuY29tLzIwMjEvMDQvMDIvdWZzLWJvb3QtZW52aXJvbm1lbnRzL1JlZ2Fy ZHMsdmVybWFkZW4K ----_com.samsung.android.email_1437749042660370 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPllvdSBjYW4gdXNl IFVGUyBCb290IEVudmlyb25tZW50cyBmb3IgdGhhdDo8ZGl2IGRpcj0iYXV0byI+LSBodHRwczov L3Zlcm1hZGVuLndvcmRwcmVzcy5jb20vMjAyMS8wNC8wMi91ZnMtYm9vdC1lbnZpcm9ubWVudHMv PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+UmVnYXJkcyw8 L2Rpdj48ZGl2IGRpcj0iYXV0byI+dmVybWFkZW48L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2JvZHk+ PC9odG1sPg== ----_com.samsung.android.email_1437749042660370-- From nobody Thu Nov 20 17:33:20 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 4dC56X3FxZz6HhPd for ; Thu, 20 Nov 2025 17:33:24 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC56W6QlRz3lsS for ; Thu, 20 Nov 2025 17:33:23 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=JAg6osEo; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=h8xAA+wf; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.151 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id 57B011D0016B for ; Thu, 20 Nov 2025 12:33:23 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 20 Nov 2025 12:33:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763660003; x=1763746403; bh=VszaOTD1kZ su3gEHacar9Isq+2Didudw5ldyeKfW3C0=; b=JAg6osEo1iDN0UxSAj/dZ8CGc6 Ki7xnF5NJd/pC2ZuvBxP8gc9Q8rGFGp76oFassqFfWNytIvV0kr0oCRJPBeRnN90 3+vDiG+Zia/iojsoBvwneLF7en0Mn/Tww1d4rjZ/Vwko1CndQ7m+4GRI+tG6TzLg gc3HOoNjgmsVTIX11akQfA6B/obV1vcArgcstLOhk3Z2UR6kd9dbPbFhpd2bWmvK ZDs8XnuQQoIyMGc8CuLyXCbleDGZZtAiYvOzBPv2JPrvjXkvid9FrNzkMj7m9ZtU 1zHFaJFd3rJRuZK02tqd/0lKRkecV0FV1YHm0Qgbo+22JtDCMd8OO06dsJjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763660003; x=1763746403; bh=VszaOTD1kZsu3gEHacar9Isq+2Didudw5ld yeKfW3C0=; b=h8xAA+wfjCydvMOPQj+e6KxdFZwyW5/4pZZ3U7TL9sdGPsN8JGH HkQ+VrsPOtEcZBnbAV0YZ8BOMm8o1cehVuAcGXhKT0nqnPEVW9gq6K0NZhVqUPG4 ColvIZWwVmZazTt5OHSQc7a4T8Xa+5OasM6hFVqFhTuUnE6OuHcC3FHfufkiwRcV 9lLIQ/TGx565d5JyBt1WMzEXT4xB7zcZO6X1DrtkbFRECXOlYUeEVRCyS8bvTCsF t5eTKxkp2L2dCoYf3SG538RXC4NYfV9rsTgMeZjf46OCHpxpnWScthxsYzBD0mcB 50xj2Lm4ycd1y/YpO+WKQxnuBrC79oiQisg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdejieelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmnecujf gurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpehvohhiugcuoehv ohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgvrhhnpeektefhudekhfdvvddtvdehie fffeevveeigeekvdetleettedufedvfeduteefkeenucffohhmrghinhepfihorhguphhr vghsshdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehvohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedupdhmohguvgepshhm thhpohhuthdprhgtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggssh gurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 20 Nov 2025 12:33:22 -0500 (EST) Date: Thu, 20 Nov 2025 17:33:20 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase - small addition in step 4) Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20251120171708.2A2B8A002606@poczta.interia.pl> 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; format=flowed Content-Disposition: inline In-Reply-To: <20251120171708.2A2B8A002606@poczta.interia.pl> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.56 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.964]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.151:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dC56W6QlRz3lsS On Thu, Nov 20, 2025 at 06:17:06PM +0100, vermaden wrote: >You can use UFS Boot Environments for that:- > https://vermaden.wordpress.com/2021/04/02/ufs-boot-environments/ >Regards,vermaden Thanks for that. Looks v. interesting. I didn't even know they were a thing! -- From nobody Thu Nov 20 19:28:34 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 4dC7gW2Kx0z6HqH3 for ; Thu, 20 Nov 2025 19:28:39 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b1-smtp.messagingengine.com (fout-b1-smtp.messagingengine.com [202.12.124.144]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dC7gT59ZZz3whR for ; Thu, 20 Nov 2025 19:28:37 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=NNlfZQYT; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=co2OKd+d; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.144 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id DD9331D00283 for ; Thu, 20 Nov 2025 14:28:36 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Thu, 20 Nov 2025 14:28:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763666916; x=1763753316; bh=HXcJGxbRNb yVat5YOm4sIGpci65UM2mG5BgBXk3j8rQ=; b=NNlfZQYTkbsPjRlB7vPHEfDSHI tc3lm94xVxTzMIKIryhBbysi928+/Mq6eapXS6DWNt8ystfyndlj9enF6uAMXtQN CuZSIMdRqRx3EegIffxu4c8nIwG7u8D/trhsrND9ngvvFk9ovqdxTY20FjXkAvAH o+fXhiFifSyS89+go+2aIPeu5szspriKST+Pm1yQPZBfZV7u0b8ZwaUYE2xh1g4K uwLtP3/cFol9ubCvJUC0y0yD5RMBeB9zIx4u64eYrG00q+4Ssy1veEr8hT1Mu/Jw QzxgINMGPh/+4ZZRZHUtdNLy6D9BKY8HAeK158iqz1g2UT0al1jFmwrUZhoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763666916; x=1763753316; bh=HXcJGxbRNbyVat5YOm4sIGpci65UM2mG5Bg BXk3j8rQ=; b=co2OKd+dggYiPXKHpZzIZvwebdsG1gpbUJgXvVkZhBATOt65A2K JdZzYYyckdmaTHmK/Iv3tROJCaD/MSu9d4QJ4byGykz3Rr5bOiF2XPe8012xxyxa ADs/ouHfTNrGYN50XeA0NTZR1SOrbAnv3QdhFM6vSmHjo4i4+S+Hb6nBHDEy6KeH v+C8YdZ7ud+ZrJGnwBa1RqCMvLE/+I2AKNtZ4KRjlOynSFQAWRwJ5M5/ojHnsI6Y FhRLLMmGa0dL7aVtgLvHEfJ2BMMSYCBGlBdDfVMCwaew6wPMU12Bz4n2r/Y58+jg J9PNtWm5o11LpBh4H+YRJVaMSSKuifefOmw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdejleduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgf eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 20 Nov 2025 14:28:36 -0500 (EST) Date: Thu, 20 Nov 2025 19:28:34 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> 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; format=flowed Content-Disposition: inline In-Reply-To: <3a98225a-0f49-4010-9e6b-8f893a069ba1@FreeBSD.org> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.82)[-0.822]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.144:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dC7gT59ZZz3whR On Thu, Nov 20, 2025 at 02:56:46PM +0000, Matthew Seaman wrote: > >This is how I would do it: > >0) Make sure all packages are up-to-date and any no-longer required > automatic packages have been removed. > > # pkg upgrade > # pkg autoremove -y > >1) Make a list of all the packages you have installed that aren't > FreeBSD base packages. You can exclude anything automatically > installed as a dependency of anything else: > > % pkg query -e '%a = 0' '%n' | grep -v ^FreeBSD > packages.list > >2) Move aside the pkg database in /var/db/pkg > > # mv /var/db/pkg /var/db/pkg.old > >3) Re-install pkg(8) using pkg(7) > > # pkg bootstrap -f > >4) Re-install all of the non-base packages from step (1) > > # xargs pkg install < packages.list > >Untried, so may need refinement, but that's the gist of it. You do end >up having to overwrite all previously installed non-base software with >an identical copy of itself. The only other alternative would be >directly modifying the pkg sqlite database, but that's not something I >can easily describe how to do. Thank you. That mostly did it. After a reboot, I had to do the following afterwards because another buildinstallkernelworld cycle still asked for DESTDIR: -1: reboot 0. disable /usr/local/etc/pkg/repos/FreeBSD-base.conf 1. move /etc/src-env.conf aside (disabling META_MODE) 2. kldunload filemon and make sure it stayed unloaded 3. rm -rf /usr/obj 4. rm -rf /usr/src 5. get the src again via git 6. pkg clean -y 7. cd /usr/src && make cleanworld cleandir clean && make -j16 kernel (no prompt at the end for DESTDIR) > >However, this does seems like a retrograde step to me. It is possible >to build your own packages from the source tree, and then update your >system from those, which gives you pretty much the benefits of both >worlds: I wanted the system to be as if I'd selected the traditional install and not the new type and this does it. So now it can use the pkg cluster just for ports packages not for pkgbase and source builds/upgrades in /usr/src don't prompt for a DESTDIR -- From nobody Thu Nov 20 23:38:16 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 4dCFCy38TCz6J6kl for ; Thu, 20 Nov 2025 23:38:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4dCFCx5nczz4N4t for ; Thu, 20 Nov 2025 23:38:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kgWk8AyC; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763681910; bh=5gEa6B6k61tOeO2cl5GGCWcew1nQ3MjSZQp3AvQtULU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kgWk8AyCU+w6zof3A+JZ21MrAiA5hS/SNu0t3aqJrmWQqKw92o44wL1fei78T4a1uqA7wuYlB4eN3d3LqDtEfyN9/lwJzObI9JVIYReZPbWRej49YQpaI2uwAfojXKbzk9aYGVkK9JqH/VDZxmu3Sc7smIIbvUWlzbHS2q7lCRWwd7xLOeU6QepLWSJDQMgbXzQclFVMWVoQZLtoMAtzRi0uG8Hc+Axl77u7OoAQdW3enV9DQz8qZ+YyeFZSr7qITd5zgW/35Xs+hIBF4gc8gp7h7HY6wL7SQSikTZWwojhKQyfyU1ZwlTZa1EvF5co2JGtK0i7I1vi6zKevB8nSzQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763681910; bh=RCfR1pQyquOujIvdDMC62dJ2/4TCHoWW8bq9vyw0FEg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hKBke7Ytb18O0P8yCQ9M9lp16WgWgzLC/lPfgMFJ2SBIfRXIR9iUGAgAzzXH719EFDgEObOpxAfPdYDrz7rrr3lG9Cn79cLKh6FidEsSbG2ClR51nmvUiYphTkI+tWt6ReJAma+vf89734dVkRVLIvD6uoOVYLt/gzr9C9KX6ULxWoryq1ssrgX/YkgK2RmjrXYXMF1XWAgqwM6GsShsKuA/d2TFgReAVxagfzBbXZySN3j59PVfwhQA/yYytgjGYwjQL+06Nd4U3VtwN573+xTn04EmlxVL0p/baaweuRPXxKNfDd0Mm/ReDK/n6iZA82pDRh1gU8h+3ZTs7gSvKg== X-YMail-OSG: V8SINaoVM1kGPnT58skcL2Py_zebWu2xn29I7fpoKTGB6xaXuN6P6_mRoGjddWI SHrm3cgowx5r0G7tY6Ksi3_yIfdNZNGAAKe7W4IS47.cDlH2MnZEa94JUV9ShmVbgshFolut6HAM NGitsmLz6y1vBabshejBrREn3mTyT8YDuSM1uXfb8E5U0xyAiPClt2umCx.gmjXaXiuQyyH5y.4b TVlYtmaqPLJx8x80tBAVQbXyUvuHbESTJ9SAHM.K38rI0A.L48y7EQKEiM1N3l1HMjFhyjBF77na 9034Ftk02N4XPpNkFc4iua_q8dygQheji2m5dONqpqMsP3jRxj25HDEXn35tK.MBJhwNBvIIkZRq zl0btcrdmO3Y2D1Ntze0Cb1lunLCa3PUcJwSCDJcgGABldB.LK2.TdvzeAX4qYbQbBlVOZPctkPu p3nBaZxydqR.enW2Lj9XEapmTsU9QyLfsqs1qLlTdK9zvtjQhlc_.KWmfRg2j35GiI4dmgFrMrXz POvsQNTKVXWOx4hWywAqRGFYiVad78rRHaWNNE6hdkcjaG3MklfFuagPDu5SbtscmxeBlIA8K.ZS fCPiqiuXGaakIBW7DrUThArztTNzBGAhh.pN__Qwkzi28Hj8p5vEm6Km2Zf_.n06GbneSlnvi7Pl qGctR6m28NeF6jxO4XnKszXO7wRpu45fxHOX47izX.Z21JB9VlryIQTJyWnqMNp4Fd9g5uhCaEzD IM_wuCpmDu6rjmmXFcY444R1edAIAKh9yeIjmeyOdENp5F007cCdNl0tKEIoolaoz8FjYLQIuDR0 ebPzmFbiRHplG9x69b7uJ6h.6X2pYZzqmbBUiXc_k6ytkVxneVudZVL24UTNtOJcWM1milFJ3TfM QzmRBN4C6k_aj.m9D3g_N7oSKiB_kM2GCJLOtrkK7dzlR1FeokbKWtsBdSx3htY.R9.19_NB2RCR 0PfxT9ruX1czrMTRP5ryEGJntjYNsc1BNuiTcwOslKuNjabH1unzHkTj7AEBL2X_6RAPT.txdjhW Gwo8mVNv2k9rhFezJS2ip4xOeIHTBs_Af6AwZQ0MdQJ.EPKYfk8Jtfzbk6QpW0XarwWGZG7yB5C4 Dr2690v6kgwq3LJQti2yVXtoTRRSA6nbSitvCoFlKoJ7W7p6j2vjy0wIx_5ngKgyC0K6K5OwzGYW XLqbtIKtms1oezKgy6QHzv7MfJncQstdRMGiGQTbuDMpQjJgk1tlnFHt4I_ZN2kBUFOcuIsNypaF y9P0fnrAI0FLQr4vckA8pKfV7AwoOnpOn.9oMUg0cLZlIKuEQsLR2luKTaqhN55C5Vj5CYKfjq_5 _q.gYQLdz9j3e5TKT5iPfGgmTYLuM5jFFZTFoyTu1w3BCte23s1bq0LRMHxfzHCB_Uqyawy5O0Gn 9tb9SPADEnER8uK.sB9gnEFP2wyV0GdH9W4zJ3ymwgCPbo9BSH4bx4K.R0hl13zlry20WGuilKNQ mXY0yqR3bGXlD2G4XuL22LP2r6.r5u8R5mR0HqJAWpg2.zmwzYH6Zz6S2meOo9Apg.IuhsaaSCsl NitEGmTpXD.PWzr_P0Owvgqycf3sJSIqV4Uar2AsJ_XSYPOFLu2ew8kqSyejQ3LqJU2BW00z26vd 34uQVRuE461jEmKfKbQM7zuKOv7U2OURfvSKTc_9RHqlggpWXyrnCa7WHj.03ZiSSTY46Y6epyS_ _Z7sYD_BHNZNtmjSid17C9O3yeBAPR6EYTZgZ.IkouSn2FADi23BOlAlPYVo4LU1MI80Erq6qBIJ Jly1t_h0nvjDSCQzEoS6uAtci_Cryc2YKvms9jq55nYuU3kHF1mULLMJWeVrzz6q8pApXYZAR7RZ nsq3ywlAc9dG3pOslOoxogvdcIIM6siT3SoZYa6Ac4D.x8LU3HG90BXpZ2Nto3UcX4dcv5aUa04y lEgI14sWEoYSwZJwiVnXmcCSrDaFQVV5m0tn2sFE.M6HsOXJJeAv_.68n6iEqbugIIk6G7Ainy_Z Kn8zThkbmiyducQQLZ1L4JKMhubLvxJVTe31Jbai752mwhQl2aaFVLSaf_LTuiCa7hSi0sqJ7P7L J3XyL51Y_MdtlXlE6oEeDgkpExkJk6LWRMt6BR0yITLRbhkeOk_CTd7qGLBQjPlG7NUTNiE_JDre kj_E6lMEffIAGZp4A1EJPjkl3Lq.h84BETcIpf76lLKpx89BZP7V.7cKbsI6O3D6rIisQaRiUQ4v 96yGEmjB95DJA9GcWu374Sfb1u5god08wPGkBc8NnGVIXWDuf0BaG6HTRvWo.uMQypbdYyoxEZc2 L5WnohbZQQTU- X-Sonic-MF: X-Sonic-ID: 643bfe97-5c82-47f1-bf4f-70289ac183bb Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Nov 2025 23:38:30 +0000 Received: by hermes--production-gq1-fdb64d996-mgwhn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7c21c8839cc609f126751e533e03b3a5; Thu, 20 Nov 2025 23:38:27 +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" [ *** i386 chroot on amd64 can get the failure on main 16 too *** ] From: Mark Millard In-Reply-To: <265F191D-5400-4A9D-BE99-F060770B5DED@yahoo.com> Date: Thu, 20 Nov 2025 15:38:16 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: <32C6B8A3-E390-48C8-8454-753511ADDF57@yahoo.com> References: <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> <87fra9fd4m.fsf@panix.com> <878qg1f8wz.fsf@panix.com> <265F191D-5400-4A9D-BE99-F060770B5DED@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from] X-Rspamd-Queue-Id: 4dCFCx5nczz4N4t # cd /usr/src/ # env WITH_META_MODE=3D make -j10 buildworld . . . Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGExprScalar.pico : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGGPUBuiltin.pico Abort trap (core dumped) *** [CodeGen/CGBuiltin.pico] Error code 134 The 7950X3D system has 32 FreeBSD cpus (16 cores), 192 GiByTes of RAM, Optane PCIe Storage media. # uname -apKU FreeBSD 7950X3D-UFS 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n281922-4872b48b175c GENERIC-NODEBUG amd64 amd64 1600004 1600004 But in the chroot: # uname -apKU FreeBSD 7950X3D-UFS 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n281922-4872b48b175c GENERIC-NODEBUG i386 i386 1600004 1600004 For that particular system I used: # grep physmem /boot/loader.conf hw.physmem=3D"5G" It resulted in: # dmesg -a | grep 'memory *=3D' real memory =3D 137434759168 (131068 MB) avail memory =3D 2708901888 (2583 MB) My odd top hack for monitoring and reporting various "Max(imum) Obs(erved)" figures shows: 1914Mi MaxObsActive 821116Ki MaxObsWired 2585Mi MaxObs(Act+Wir+Lndry) 1617Mi MaxObsSwapUsed, 3488Mi MaxObs(Act+Lndry+SwapUsed), 4166Mi MaxObs(A+Wir+L+SU) [at such a time: 4193Mi (A+W+L+SU+InAct)] I had to build main 16 for the i386 myself, based on the /usr/src/ from the official pkgbase system in use: such is no longer available. I did not make changes to allow SIGABRT to core dump. -j8 did not fail. -j12 ran out of RAM+SWAP. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 21 00:03:17 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 4dCFmp5HnTz6J7wF for ; Fri, 21 Nov 2025 00:03:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4dCFmp142Nz3BxM for ; Fri, 21 Nov 2025 00:03:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=XqHFxpvM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763683410; bh=gkCKPPgjuZdjtBQOLH67ZMNZL9ISgKyvmLP9Hjsdsh8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XqHFxpvMMzce/Ri6X7tMQ7ZTGvJxUXkG8a6eZn06UZKkC9uApL8TTSKU5gO4U2O0XzOZW+QTl2vmJgu7A33XeEx75o0RlUqmbv5BT6UGhss43GXTA+IZzt+ZgHGhPFliXPn508JrNq+CpJd53gjvFPAlGo/wdFqBAm6liBMs4+MgWKB4cP/2Ii4ZaQQao9iY8HJkNRpI57IYGWv3ufrl6dheAVKupyvtrOJtFE2AeETaQXW26soLUZfLwpT+SGpKfcp/8pwg+Jxb8+akVAkMFQ2Ev42uIKuk6bgomzEVBkqab6E8xNT65zCMidhnEgr/pd1l2Ee3p+TePe1weNEAhQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763683410; bh=8jsKNC+W0ChnZ/o+R2FLSuP9uyFCoGJ6IWq3cZmqIaw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SzHHUvHEGkJYa3pPNqremRir/UXkvX86tQnKUwmTOZjus583pE7V9gHxPjl+5UU8lS2XTEElA+x09GM7ArmjuHeSgJmOztJQgrbA5NY1oo86JdXKhli4OzZVhCy9V+3LZmNOYhhqCEQvePkW7pT1wL+LGUMJdLyH08YUpzkGx8EMsHAlZWUabwdM6TcTxAeKx8V9agVH6/eNTjfVBe/y1YV5GrSvOH68crQ2mtmhqySfKVGD9xYXtH2VQ48c62B8gu1d267J0CqxH3lLBACMu9wn9+tn8hwW3W83zpGt+hKRTyEWy4vThh/Tl4nqUg/U1wzvrOqoJ98vuLPkKEcAJA== X-YMail-OSG: W2VVeY4VM1moHUVCslenDjwdEWMaqMj1wKAUmCD6lHYFHgB4uEQ5xJqlvNaO6Ni yJruUbFk4P86d_QDMUpeazVfEfARL1122JFAm75cCcrP0iAGfLyPIq78TClZlVuV1mIlaCLNbWi5 jBBTKJ6krODn.ech5cRplo8Ks2LsR_J0MfOQcv6hBmStuVfJRClyqx70vd7cvdiWvJ0ovw.CygX. Y47RwLgznsLfTMgNXh9C.W3Ma_F8gODpT__rx.TpgOxmdmc_XbV3JvuuJUc5DD0aWJOC94_OYZOx xEDgEswgpFHmCiKFqb1gmaT2AY.yLvXLGHQD_9fBXaSgkyKXVEUJylr6YkJJt2hky3bocecMSVbv WiijZDGb9EMfsIFsnFEDI9WK6KmSkmGWErNv8vwH5tfMQvWnPDFy39B_fyW0ZK0cJhHJdEKXBc6U Ld66GzaDkZSlzrjkBGKw7VGaV3wjA8z3Vak_om.UmxkXJbMpT3Lu36E0WOuqo_tDLj8LV3OgW9Wa PmafRntLlLUk9LD1WzrGq8m3oUkd6VT7j.bYDuUAaGds4_v1LjO8wby4GFmqBvYzpHCXXwHDt2Gl xk4BDI81812xYbiH82bORRaz.BbN2HBJBYhlggPn.A9xzGSKBbtC9vOnyXJvdSOTjRSg.dnm2nEL .eomgbfTNdLYh28KYXf0n03QJcZ9phtGP1zCoUcNeSwH0ff9yJKIep_ppI1i8axteGHslJi1fM.h 1HJLojZLlph1Z6tRcGYrntIw3TkpR_MnwrKX3ZMfNpyAwI4GnXb4zS4MavaNppXldimP44qJKOB8 HBBQlsQSsgVJkiDhfFUqlGV3kzRjDGGYTbmKGUICV7HuZD_p4EJYNVfYMRWVyhQFbsP2jqpJvLu9 .5f83X0IWoHxO1ppmx4dz0g8qsnWAsYvVSMtYh19R93c0Q2T61veB3De.itbqD2WdV.IBhlzrdHp pgo1qepSIGov3g_mb_HoC2Xpl7cXcwLCbTMBNqeDzdOVQoo4CRms0pkwLo_8l21xF.Qbcb6KIH4t GEJ6Ga9jPFMPypQSeS.Viwf_Vt_Q_dPxoUQ.hMNjeQBYPhPZAJ6rP8nAZ01fJP7B7PDssCYNMLvh d3xEMDc_.U1zcV6kG3E1ceJ0G1vK0O9N3osGam_BDDZ_IfVYhAVJiDpX55J0_j.bX8lXXjBuNR0N jDUvDBOG_7QMQ1yEzfsAtY3lbUWLDHU046P9XGa5TOkCBKfBibNzSZTs3hI5ybppL5LvUF0Td4lm GVA1Sjwbxz7lY6lBBFcAamceM_ScnH0nqMg3iBshbdF4mIGCq.tQw3IW_rf7q.OzJR3o.XbHht2I WNPomlZ97cH49be0iTi7HVISWAxpwV7PMmvI8RimhCAI.0bpqWVB0SS6RQiRwOc_Qlo5dmSB1IDA FsZx9Kmlt.X9M1.hvYaRuV9GTTkrpuMW13DFe9OwBX77M5mAWr0qnirqTg80kP.cQl0HRdrAWE37 J2Q3M7rt2qjDVq3grw8nR_YQBjm27AV3PRLInfwqxlp8.7BbwhJtYOzsM0HokUWBfZBXU5hBRMNS Zz4n1VZFpUc4vFVUt44AoVz0.Dvzzdx2WsNXMdETbbfYkQUBWHMvrbXVzj0LBg4fm_DshbJfRFk2 MxiEVFEgUjs4wb3Bs6J3EF0mocVy_zY2LSS79du1WAsO9X3xgAvttSY7j8gRxm4j8frHMYK0H8bi rSUnRA.a1V6yiJYl0PEdxDgWKAXXeMjv8dxDZz7iu_wm8mxP0bKdGkaHuxR6JvNmS3rcGv4mYlIi 35s3P8NZgmml1XavWkJ.sBFK3.N727KZPga1l0vRX8qzjfmp2nByLiH2R4ADKRv6TvyqElIKZZmw WcMf3Rbu1lfInRwhGiN.NSEtFn4nsBw8JPjlFo_G3XwWxbLtRUN8cDVFudLT3aJjEDa2zrUyuyXW rSd3K423AJLD8pdjtIWvhZVVGvW0Ui2Iuehb5DmpU8Io.WSPpYoih_SVl0IFS2r0USFr2j3_giYL OvO6GqjGqfC1yblCjGJJjCIusHmBfTETkDwDSKoQHMHXWT.mf2URuGvM4ZH4QshouKKlSefv9iBs cW8O5DgTgv2eCwQhfW01sAMAapYVJNgNfLDFyZVoiQtq5IEN2_2MqZwKgOQcKLUS5Jph2oh2mjpx 5gnnEI_WzoMxBKpsUqOesZdoxMT71LvZ3zpdMnGlcnU5rjku97xv1STXulNuzVQleZFx_PRYyRay 7qaokVFsWWXyazbtCpTYfHuqBf4Jw1ybzs_Wnn1MIJLozOHmrS62Dm1hr1t2JefvvVJqq.MbD2Y9 KOsM7fiK4Rpo0rw-- X-Sonic-MF: X-Sonic-ID: 50ffae4e-6ced-4b7c-99eb-74f43fc8f390 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Nov 2025 00:03:30 +0000 Received: by hermes--production-gq1-fdb64d996-kqmgv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ac7f43ce32985d882f52ed119272ac00; Fri, 21 Nov 2025 00:03:29 +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" [ *** i386 chroot on amd64 can get the failure on main 16 too *** ] From: Mark Millard In-Reply-To: <32C6B8A3-E390-48C8-8454-753511ADDF57@yahoo.com> Date: Thu, 20 Nov 2025 16:03:17 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: References: <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> <87fra9fd4m.fsf@panix.com> <878qg1f8wz.fsf@panix.com> <265F191D-5400-4A9D-BE99-F060770B5DED@yahoo.com> <32C6B8A3-E390-48C8-8454-753511ADDF57@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4dCFmp142Nz3BxM On Nov 20, 2025, at 15:38, Mark Millard wrote: > # cd /usr/src/ >=20 > # env WITH_META_MODE=3D make -j10 buildworld > . . . > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGExprScalar.pico > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGGPUBuiltin.pico > Abort trap (core dumped) > *** [CodeGen/CGBuiltin.pico] Error code 134 >=20 > The 7950X3D system has 32 FreeBSD cpus (16 cores), 192 GiByTes of RAM, [Silly typo fixed: GiBytes] > Optane PCIe Storage media. >=20 > # uname -apKU > FreeBSD 7950X3D-UFS 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n281922-4872b48b175c GENERIC-NODEBUG amd64 amd64 1600004 1600004 >=20 > But in the chroot: >=20 > # uname -apKU > FreeBSD 7950X3D-UFS 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n281922-4872b48b175c GENERIC-NODEBUG i386 i386 1600004 1600004 >=20 > For that particular system I used: >=20 > # grep physmem /boot/loader.conf > hw.physmem=3D"5G" >=20 > It resulted in: >=20 > # dmesg -a | grep 'memory *=3D' > real memory =3D 137434759168 (131068 MB) > avail memory =3D 2708901888 (2583 MB) >=20 > My odd top hack for monitoring and reporting > various "Max(imum) Obs(erved)" figures shows: >=20 > 1914Mi MaxObsActive > 821116Ki MaxObsWired > 2585Mi MaxObs(Act+Wir+Lndry) > 1617Mi MaxObsSwapUsed, > 3488Mi MaxObs(Act+Lndry+SwapUsed), > 4166Mi MaxObs(A+Wir+L+SU) [at such a time: 4193Mi (A+W+L+SU+InAct)] >=20 > I had to build main 16 for the i386 myself, based on the /usr/src/ > from the official pkgbase system in use: such is no longer available. > I did not make changes to allow SIGABRT to core dump. Dumb mistake: I *did* make changes to allow SIGABRT to core dump. (I had done so earlier when figuring out how to do that. I had left the source code change in place on that system and it was in the copy of /usr/src/ that I put into the chroot area.) But I do not have pkg or gdb for the context as stands. > -j8 did not fail. -j12 ran out of RAM+SWAP. >=20 For reference (white space detail may not be preserved): # diff -u = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp.or= ig = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp --- = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp.or= ig 2025-11-15 07:58:41.000000000 +0000 +++ = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp = 2025-11-18 01:26:50.661412000 +0000 @@ -345,7 +345,7 @@ #include =20 static const int Signals[] =3D - { SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV, SIGTRAP }; + { /*SIGABRT,*/ SIGBUS, SIGFPE, SIGILL, SIGSEGV, SIGTRAP }; static const unsigned NumSignals =3D std::size(Signals); static struct sigaction PrevActions[NumSignals]; =20 # diff -u = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc.orig = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc --- /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc.orig = 2025-11-15 07:58:41.000000000 +0000 +++ /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc = 2025-11-18 15:37:06.502424000 +0000 @@ -215,7 +215,7 @@ /// been ordered. static const int KillSigs[] =3D {SIGILL, SIGTRAP, - SIGABRT, +// SIGABRT, SIGFPE, SIGBUS, SIGSEGV, =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 21 03:34:28 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 4dCLQs6BHcz6GQMZ; Fri, 21 Nov 2025 03:33:25 +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 4dCLQr2LjDz3TFH; Fri, 21 Nov 2025 03:33:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AL3YT4J068575 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 20 Nov 2025 19:34:30 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AL3YSDO068574; Thu, 20 Nov 2025 19:34:28 -0800 (PST) (envelope-from fbsd) Date: Thu, 20 Nov 2025 19:34:28 -0800 From: bob prohaska To: Warner Losh Cc: "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> 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: X-Spamd-Bar: / X-Spamd-Result: default: False [0.95 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.67)[0.669]; NEURAL_HAM_SHORT(-0.62)[-0.621]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4dCLQr2LjDz3TFH 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"))) > #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. 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-) More seriously, is the path forward even hinted at yet? It seems jemalloc is getting considerable attention but I'm not reading reports of 'Eureka!'. 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? Many thanks to all who've helped! bob prohaska 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 From nobody Fri Nov 21 07:12: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 4dCRJB31dCz6Gjrs for ; Fri, 21 Nov 2025 07:12:58 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dCRJB1CqHz3sCx; Fri, 21 Nov 2025 07:12:58 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763709178; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aheaZkn47dANNpNUtWcbwOSgMdOYaCQXCjq2ggZhL7I=; b=Srl9BKgClkHB4M1Jcq2JYSRwvpyoxg2M4yopVGLrUYa/wjyZpAa2Z21poVl1HaUlh4nfV/ AqWY+gPiYz8LZyp2U6j2kBn02k0SHfBrujLo0Zy9yMtP1cmW4oEHgtUFzyPJb3BMUHYMnh atyp3a3I28YCm6qqa2CiB56/jzcGvW//30YHF3zKeFlPmXxKPzDtlSRrx1jX//GEfH7LVW TJEQ8MXk5/MP5/rwzkgKTlmorO+BuHEiUXAtFCLZXgUqGFU9RiCeM4VsbUYZQYX0eGrlYY ymkS4Jy4S5IKMZWtrtq9M936dnIwCZrUS2VrOjKqBAG9G6+6qr2YmSY584WAoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763709178; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aheaZkn47dANNpNUtWcbwOSgMdOYaCQXCjq2ggZhL7I=; b=iLrBcg6N3PqAqt2F/icYA25VwhICiTnleBFm7Mk2vcEuw9nhLZd0zhVvxhZ/Av7Hv9M5QZ xZX64KCibYIOR4H5ya64dD7apY1de7CoHCGKuVHvjztkTTGerPIETcPfPUTldGjgWXIToF qG423XR702/U1n+s8JOutzcJLu1i9hSvZ/PQouCRg3SO4MJvknOIT4wb2IAQrxrshXA5So DSW3524SIQJeDagkQsjfJGvW8AQSCjVLteC3yS1QBznczbcYUt5TAN4o6zk9uw793UJT7X O2WwMf/qiaC4+ZQFGlegho1qLg3F9x49dgVhUF7QVvOVavaHvjJZWhTWLg6v8g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763709178; a=rsa-sha256; cv=none; b=pYPDufup9svmQGBGTy9quvoGh5yXfwiNJdAUwydbJY7LMn251izpp4/Zf/l0TzgRQvFN+1 t5BVf+XHM8kraLwlseELARFd6bqDS+lcX/28tZgLWBKiQRlZQAPeTMr2WNvRUmFQ3y4PKY 0pfkUXu+zKJ2bUcjQ4QhVDoY1Zc3g5SaqZrhN7L1PBBVaYy751x0mGqbtUTpmJsVek5j1p +EQJ3/1S4dJizsJS4jcN72hBIgHu7krBBwdwPct8WO6yiBqbggxHbMTS+HSo1Lu8mNcjE0 JvJQfVP7Zxy+z/ME9AxrNB/vGvEwD9MOt8zsrJbW68qMRywaQjDQKIT5D5ztnw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (internet-251.radiolinkplus.cz [109.205.241.251]) (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 4dCRJ95PjKz1LRS; Fri, 21 Nov 2025 07:12:57 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> Date: Fri, 21 Nov 2025 08:12:55 +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 Content-Language: cs, en-US To: FreeBSD Current , Konstantin Belousov From: Michal Meloun Subject: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have confirmed that jmalloc assertions are caused by mmap() failure. It can return non-zeroed page(s) for mmap(MAP_ANON), which is clearly a bug. I have confirmed this on native ARMv7, and according to Mark, it is also reproducible on ARM32 and i386 jails. I think I saw it also on a memory-constrained (4 GB) aarch64, but I cannot reproduce it yet. Have somebody idea how to identify vm faults associated with anon mmap to trigger detection of this failure in kernel? Or any other hint? Thanks, Michal From nobody Fri Nov 21 08:36:36 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 4dCT8x3x01z6Gq93 for ; Fri, 21 Nov 2025 08:36:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCT8w6kHmz41dl; Fri, 21 Nov 2025 08:36:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AL8aa7J014692; Fri, 21 Nov 2025 10:36:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AL8aa7J014692 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AL8aajB014691; Fri, 21 Nov 2025 10:36:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Nov 2025 10:36:36 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> 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: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dCT8w6kHmz41dl On Fri, Nov 21, 2025 at 08:12:55AM +0100, Michal Meloun wrote: > I have confirmed that jmalloc assertions are caused by mmap() failure. It > can return non-zeroed page(s) for mmap(MAP_ANON), which is clearly a bug. > > I have confirmed this on native ARMv7, and according to Mark, it is also > reproducible on ARM32 and i386 jails. I think I saw it also on a > memory-constrained (4 GB) aarch64, but I cannot reproduce it yet. > > Have somebody idea how to identify vm faults associated with anon mmap to > trigger detection of this failure in kernel? Or any other hint? I think It would be much more visible if freshly allocated anonymous pages are corrupted. A similar mechanism to get zeroed pages is used to get fresh page table pages, and corruption there must cause a lot of kernel page faults with 'invalid PTE bit' hw reports. But of course everything is possible. VM has an optimization where we track known-to-be-zeroed free page separately, by marking them with PG_ZERO flag. If allocation needs a zeroed page and the flag is set, we skip calling pmap_zero_page() on it. Also, in vm_page_free_prep() when we are told that the page is zeroed, with DIAGNOSTIC enabled, on amd64 and arm64, we do check for that. So lets add slow check for vm_fault code that supposedly zeroed page is indeed zeroed. Can you try to catch the issue with the patch applied, and DIAGNOSTIC enabled? Patch is arch-agnostic and I believe should work on armv7, although obviously causing slowdown. commit 1a9e20dc8f7faadeb839ea6a04c83a4bf2652925 Author: Konstantin Belousov Date: Fri Nov 21 10:34:51 2025 +0200 vm_fault: under DIAGNOSTIC, verify that PG_ZERO page is indeed zeroed diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index 2e150b368d71..32bec33502fb 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -85,6 +85,8 @@ #include #include #include +#include +#include #include #include #include @@ -1220,6 +1222,20 @@ vm_fault_zerofill(struct faultstate *fs) if ((fs->m->flags & PG_ZERO) == 0) { pmap_zero_page(fs->m); } else { +#ifdef DIAGNOSTIC + struct sf_buf *sf; + unsigned long *p; + int i; + + sched_pin(); + sf = sf_buf_alloc(fs->m, SFB_CPUPRIVATE); + p = (unsigned long *)sf_buf_kva(sf); + for (i = 0; i < PAGE_SIZE / sizeof(*p); i++, p++) + KASSERT(*p == 0, ("zerocheck failed page %p PG_ZERO %d %jx", + fs->m, i, (uintmax_t)*p)); + sf_buf_free(sf); + sched_unpin(); +#endif VM_CNT_INC(v_ozfod); } VM_CNT_INC(v_zfod); From nobody Fri Nov 21 09:03:44 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 4dCTmF40cxz6GsTN for ; Fri, 21 Nov 2025 09:03:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCTmD4tpMz45QZ; Fri, 21 Nov 2025 09:03:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AL93iVJ016155; Fri, 21 Nov 2025 11:03:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AL93iVJ016155 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AL93igT016154; Fri, 21 Nov 2025 11:03:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Nov 2025 11:03:44 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> 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: X-Spamd-Bar: / X-Spamd-Result: default: False [-0.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_MEDIUM(1.00)[0.997]; NEURAL_HAM_SHORT(-0.73)[-0.732]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4dCTmD4tpMz45QZ On Fri, Nov 21, 2025 at 10:36:42AM +0200, Konstantin Belousov wrote: > On Fri, Nov 21, 2025 at 08:12:55AM +0100, Michal Meloun wrote: > > I have confirmed that jmalloc assertions are caused by mmap() failure. It > > can return non-zeroed page(s) for mmap(MAP_ANON), which is clearly a bug. > > > > I have confirmed this on native ARMv7, and according to Mark, it is also > > reproducible on ARM32 and i386 jails. I think I saw it also on a > > memory-constrained (4 GB) aarch64, but I cannot reproduce it yet. > > > > Have somebody idea how to identify vm faults associated with anon mmap to > > trigger detection of this failure in kernel? Or any other hint? > > I think It would be much more visible if freshly allocated anonymous pages > are corrupted. A similar mechanism to get zeroed pages is used to get > fresh page table pages, and corruption there must cause a lot of kernel > page faults with 'invalid PTE bit' hw reports. > But of course everything is possible. > > VM has an optimization where we track known-to-be-zeroed free page > separately, by marking them with PG_ZERO flag. If allocation needs a > zeroed page and the flag is set, we skip calling pmap_zero_page() on it. > > Also, in vm_page_free_prep() when we are told that the page is zeroed, > with DIAGNOSTIC enabled, on amd64 and arm64, we do check for that. > > So lets add slow check for vm_fault code that supposedly zeroed page is > indeed zeroed. Can you try to catch the issue with the patch applied, > and DIAGNOSTIC enabled? Patch is arch-agnostic and I believe should > work on armv7, although obviously causing slowdown. I also made the vm_page_free_prep() check MI. Please use https://reviews.freebsd.org/D53850 instead of the previous patch. 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 From nobody Fri Nov 21 16:30:54 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 4dCghQ5bdRz6HR7j for ; Fri, 21 Nov 2025 16:31:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4dCghN5fd2z44nc for ; Fri, 21 Nov 2025 16:31:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DFyhSLOA; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763742669; bh=VmUR4WXcxHjPRSxPyvKywFK7BFXtY38n8sAZnyD+cAk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DFyhSLOAnOFPGzEG7EfrR1tutlKz0pEnXCedfc92tDsD1l4QEPboM5UBBgTynTibkbv9vJjgZe53CbbtRNdAlO2Nafxld+P9yV7nbLZPXyDCiRsz/8s7zsk9ZXhwwUPvLK6vOABlCRTPvZ40JlzX/SmfGPFmDzcIGgW8u0Bjb+GOrC/lQOGh6geX/3/c0614LkTdnAV0n0mb5flEwYE0Htjo8Csndnbspdozcq4Y7QJFIjqx9tzQTOAPGS6JB9xdywuVpBRY9MTTVa/kADrvlGVaN6xOW/q2H8lV+0y9jGnV8qkqMyvbJ4/HQaOYvnVr7UBJS5xnAscYkgvvqwZgBA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763742669; bh=NuxghDxOzWurArw+tJDtlZ1tE6k5XyNrTh9att4ke88=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XWZYxDWdNXRIhOiREop+S65tFEKgRVihSu8ZoHoMq+YG/OGCCA9mOm31Q298buWrDUvs5kXJX6a5wLCr5yhKWLJSSzdc+X7NXME9jnuF1UQtfY66539K+y2KEXOKmoxz4orWuxql+9EJLE+2REWzMsmtKt5VVu8DfUvRCByvUOCkucQctnTCk9zztQba5qJE4S+AIFHjH2b0kAsYqIZb/HSOhlPt4zqgvbZzGpuml0JIZe2jZl1SesDxUH1sRnVIvx1fgM0G2QaZV2bbbRYc0xqxkt4ic4Nsxtr6wFHO/wldystqPPh7sk131n8Tt5kYGKvlotECS3/7LJskkrFxDg== X-YMail-OSG: APKoy5sVM1n3GTBxfqsOwt6q9TUM4ln5UZOYrJKNl3uH88jbLxL9DgjB.ye80uc 06hCDJvT7eGrW9Z9JSGkcUeZ89.IfUU3Ty_nmEAs_sBfo82lFniQwXyNZAa9kPG5R_mbQmr5nvKm UQhZPVHw9ilxvya9TCXQ6r_qPqGVXpcFFb_.WTUr3OWU5b28RYoOWah1NSpJ5z_vqA2tIDcVWUyV 1OQnGl9fkF1MRPMo0E3IpvncAq6JcnuOzs01jsiNPTGHPv_RjOmpBH1zc.UAZOYzaymbhmlpcHLf xYGvIqyfmhxFdjS47j6paKfn5.2I3sS_7O7Z7Lxl7b3F_HoQtyFB_HoxNzxFGWzYiNEHbtrjzDfH EajGDtaoqSRSaz6sE6MaRaTRg5Qe5ZmZxUTBbBQb66eQF_pW4o4.Ptn3IgowaRffHRumTz3q3Q7h NRXqfJYG4KJAq_Df.MZuvwRb0ijtTpPiuaFINdqhoRwfJnmxfQ5uBC3r8Z_KPPLxsAuoVBG8PQKd 4Cf2LNOD1MvKLbb0Y7B1OgSt.Ip.MQvdbwIrYqbz9SKRNDJ45jPlAOVobXCr.SJnn4sjGj2zKd_P DuwsA_muM5XmDtzxuL5.jpy7rTVZbn0yMrXa4KKnMF.1azXp5QF2qr6NDngSNrAxC37BsStLpRBt vl73AhkZQQs7SFDARzooRZcomIIZScBrnrgqCnedjLsNnPDJsQkOmFyJ_QI5vQs7T8Vm_3IVsnK4 pudHwKwCiJXMaTKo1zoBrTpUdCnVn25OEXGPQEiZKLZBFL6TRYEwdl97uZQwQSEndhqf2LTU4pSp cXIvyh3.oWwoI4WmCIV.Y3oA3oRl3T_KvHiP.RH9qprQ_bu2XC3sdrvz1Ts8vZCueDON93cj8gMA nle0Cy67DLCQgwerNz6BW.a8T.Ob0WzI2qrtef_g8M3H4OOOUDxEqS9eEW_J9p6RKW.4xIbru5VQ LdG22ljuSWPlg318MUXPwRf8V_8JpQESRcy_KDelGWU40ytSbe0WuOBzWz24EXjwDDsYfwtRoYDm wsk3uwCUyI7ywPSH9JO980u.HZ9nimGU85irCl05E5rA1aVBDc.7_gNxVroeakfj4caFxYjrGS.r dBFBEETrBU5XodODifq3KjvfZWWw7BeuQ.AmZHoC37TwGRdARkAFpg2H.cGh4NviZfdxAc9i182w Eit1WfBAN9W1ButER7yax_UK5SQDBRf5LfZ9Jij1gFah3R4c8boZH00qpfQ0.J3e.mRskdqG35_C W3Oms.lx9KzZwAvYebilOpuLp93YP23TtYTm1Gbj0tYuPgGEgxLsylIpyRxahFGa5alFCLhwyUpa WLmSdtg9h_vFr.7FEeJkDatRztXMvWFFYxEkxpdgJTRGbXn3M03Kh9LEr8kIYkCiWYywKn4p5pXF c3gS.mkf3Az57ziWTJ7_9yljYCbY3Va8PC56n._6uuXgd_0WpuzCwxRKgeyjoouegRZ3cu.kDhoO M64wHFvUhogEEej1SXlBsWCd80mARcyH2aYK7CMyT0VSUGRDezEw9D3c9ZHWOTgfpd3qvOmrrMW2 z995OJQqX6aBdHqiBwj18dqjKZYTO4VZSvxnrpR9K192IxQJpZwtWdlyglJIl1QZutCN1bC3Z_8L eQhMyII_MSjRdIaplFY4o43QcmobbHGNRmF9HO4URWCsyX9UQEGcOR83AykYPSFNy6KY4UkzwI7X vWbQhyOx3EixGuuub5Ln4dJ6Yz_fB7CGLQqby5AOg5jg3hfmGfZti0ZxrAJecsZr7OAT4AT3014E 16uk.jSdYjLMZjavYOQIzf5EyxFiQ4vNalZCcfv2oK6g7AIgg7zgA_L1A74GgPJi.1s9sKhzoU8B iwxq8DbrYApNhwBm2ObWboYndK.IFHXfv9.j2yWlBe07pOCeU.tLflbW_XgEmBvvtANT4e1mHIFa j5mI8Z0JDvLZ5Os0sdiZR3VQLZyLdlM9N68IQmiA5JP6W1TQjjlCfiWKfuwtbSx0hzFU.pHu4SdB rIKdhYrepHZ4ha1Z38FHoZ6ZORWA8zlZhU2Et6BMUdV04Uzy0yre5nTL_6uZysE9IVP_7KRNNYV4 Fp21rLVDf53FXGbKxvBatGvWH6ayBdS6wrOHS38tDwdMm6lucdNRjQOpDxJImRzAZIFmF9unkwc4 oflD5b7m3U.pK8S4Xo_f3JArnvbkMAxw3x2VIEwhGH.9s6qqXLZDoV1GFBZ9pvFcy.wPZxluRoG4 DCJZBYqx7GK71XSe7Nqx2H6A4Vkjucvfcsl6tgOxDoeDWoxQUSLb6FpmhWCewWWINg4mgIQhqfyh CKaSQebJICwt.fcE- X-Sonic-MF: X-Sonic-ID: a802a585-1689-4cff-bab4-0f55595cdec4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Nov 2025 16:31:09 +0000 Received: by hermes--production-gq1-fdb64d996-jgmsv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID daba02c70f0aa685e3699ff0ee96f42a; Fri, 21 Nov 2025 16:31:05 +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" [ *** i386 chroot on amd64 can get the failure on main 16 too *** ] From: Mark Millard In-Reply-To: Date: Fri, 21 Nov 2025 08:30:54 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: <5A0EABFD-A84F-444E-B41A-BC2F9584FF99@yahoo.com> References: <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> <87fra9fd4m.fsf@panix.com> <878qg1f8wz.fsf@panix.com> <265F191D-5400-4A9D-BE99-F060770B5DED@yahoo.com> <32C6B8A3-E390-48C8-8454-753511ADDF57@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.961]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.30:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from] X-Rspamd-Queue-Id: 4dCghN5fd2z44nc [lldb works for that i386 core dump.] On Nov 20, 2025, at 16:03, Mark Millard wrote: > On Nov 20, 2025, at 15:38, Mark Millard wrote: >=20 >> # cd /usr/src/ >>=20 >> # env WITH_META_MODE=3D make -j10 buildworld >> . . . >> Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGExprScalar.pico >> : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" >> Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGGPUBuiltin.pico >> Abort trap (core dumped) >> *** [CodeGen/CGBuiltin.pico] Error code 134 >>=20 >> The 7950X3D system has 32 FreeBSD cpus (16 cores), 192 GiByTes of = RAM, >=20 > [Silly typo fixed: GiBytes] >=20 >> Optane PCIe Storage media. >>=20 >> # uname -apKU >> FreeBSD 7950X3D-UFS 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n281922-4872b48b175c GENERIC-NODEBUG amd64 amd64 1600004 1600004 >>=20 >> But in the chroot: >>=20 >> # uname -apKU >> FreeBSD 7950X3D-UFS 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n281922-4872b48b175c GENERIC-NODEBUG i386 i386 1600004 1600004 >>=20 >> For that particular system I used: >>=20 >> # grep physmem /boot/loader.conf >> hw.physmem=3D"5G" >>=20 >> It resulted in: >>=20 >> # dmesg -a | grep 'memory *=3D' >> real memory =3D 137434759168 (131068 MB) >> avail memory =3D 2708901888 (2583 MB) >>=20 >> My odd top hack for monitoring and reporting >> various "Max(imum) Obs(erved)" figures shows: >>=20 >> 1914Mi MaxObsActive >> 821116Ki MaxObsWired >> 2585Mi MaxObs(Act+Wir+Lndry) >> 1617Mi MaxObsSwapUsed, >> 3488Mi MaxObs(Act+Lndry+SwapUsed), >> 4166Mi MaxObs(A+Wir+L+SU) [at such a time: 4193Mi (A+W+L+SU+InAct)] >>=20 >> I had to build main 16 for the i386 myself, based on the /usr/src/ >> from the official pkgbase system in use: such is no longer available. >> I did not make changes to allow SIGABRT to core dump. >=20 > Dumb mistake: I *did* make changes to allow SIGABRT to core dump. > (I had done so earlier when figuring out how to do that. I > had left the source code change in place on that system and > it was in the copy of /usr/src/ that I put into the chroot > area.) >=20 > But I do not have pkg or gdb for the context as stands. >=20 >> -j8 did not fail. -j12 ran out of RAM+SWAP. >>=20 >=20 > For reference (white space detail may not be preserved): >=20 > # diff -u = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp.or= ig = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp > --- = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp.or= ig 2025-11-15 07:58:41.000000000 +0000 > +++ = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp = 2025-11-18 01:26:50.661412000 +0000 > @@ -345,7 +345,7 @@ > #include >=20 > static const int Signals[] =3D > - { SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV, SIGTRAP }; > + { /*SIGABRT,*/ SIGBUS, SIGFPE, SIGILL, SIGSEGV, SIGTRAP }; > static const unsigned NumSignals =3D std::size(Signals); > static struct sigaction PrevActions[NumSignals]; >=20 >=20 > # diff -u = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc.orig = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc > --- = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc.orig = 2025-11-15 07:58:41.000000000 +0000 > +++ /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc = 2025-11-18 15:37:06.502424000 +0000 > @@ -215,7 +215,7 @@ > /// been ordered. > static const int KillSigs[] =3D {SIGILL, > SIGTRAP, > - SIGABRT, > +// SIGABRT, > SIGFPE, > SIGBUS, > SIGSEGV, >=20 I'm used to lldb not working for armv7 that I did not even think to try it for i386 until now. It works for doing bt for i386. But the ehooks_debug_zero_check call has addr=3D : (lldb) bt * thread #1, name =3D 'c++', stop reason =3D signal SIGABRT * frame #0: 0x24bd378b libsys.so.7`__sys_thr_kill at thr_kill.S:4 frame #1: 0x2ab2231b libc.so.7`__raise(s=3D6) at raise.c:48:10 frame #2: 0x2abcc73b libc.so.7`abort at abort.c:61:8 frame #3: 0x2ac10440 = libc.so.7`ehooks_debug_zero_check(addr=3D, = size=3D) at ehooks.h:0 frame #4: 0x2ac0ccfa libc.so.7`__je_extent_alloc_wrapper [inlined] = ehooks_alloc(tsdn=3D, ehooks=3D, = new_addr=3D, size=3D, alignment=3D,= zero=3D0xffff917b, commit=3D) at ehooks.h:208:3 frame #5: 0x2ac0cc5a = libc.so.7`__je_extent_alloc_wrapper(tsdn=3D0x2adf90a0, pac=3D0x2b0015e4, = ehooks=3D0x2b000080, new_addr=3D0x00000000, size=3D167936, alignment=3D64,= zero=3Dtrue, commit=3D0xffff91e3, growing_retained=3D) at = jemalloc_extent.c:1003:15 frame #6: 0x2ac0c58e = libc.so.7`__je_ecache_alloc_grow(tsdn=3D0x2adf90a0, pac=3D0x2b0015e4, = ehooks=3D0x2b000080, ecache=3D0x2b0036d0, expand_edata=3D0x00000000, = size=3D167936, alignment=3D64, zero=3D, = guarded=3D) at jemalloc_extent.c:126:11 frame #7: 0x2ac3c73f libc.so.7`pac_alloc_impl [inlined] = pac_alloc_real(tsdn=3D, pac=3D, = ehooks=3D, size=3D, alignment=3D64, = zero=3D, guarded=3D) at jemalloc_pac.c:124:11 frame #8: 0x2ac3c696 libc.so.7`pac_alloc_impl(tsdn=3D0x2adf90a0, = self=3D0x2b0015e4, size=3D167936, alignment=3D64, zero=3D, = guarded=3D, frequent_reuse=3D, = deferred_work_generated=3D) at jemalloc_pac.c:178:11 frame #9: 0x2ac3afe0 libc.so.7`__je_pa_alloc [inlined] = pai_alloc(tsdn=3D, self=3D, = size=3D, alignment=3D, zero=3D, = guarded=3D, frequent_reuse=3D, = deferred_work_generated=3D) at pai.h:43:9 frame #10: 0x2ac3afc9 libc.so.7`__je_pa_alloc(tsdn=3D0x2adf90a0, = shard=3D0x2b0015d8, size=3D167936, alignment=3D64, slab=3D, = szind=3D49, zero=3D, guarded=3D, = deferred_work_generated=3D0xffff92cf) at jemalloc_pa.c:139:11 frame #11: 0x2abea7a8 = libc.so.7`__je_arena_extent_alloc_large(tsdn=3D0x2adf90a0, = arena=3D0x2b000500, usize=3D163840, alignment=3D64, zero=3D) = at jemalloc_arena.c:338:19 frame #12: 0x2ac117ea libc.so.7`__je_large_palloc(tsdn=3D0x2adf90a0, = arena=3D, usize=3D163840, alignment=3D64, = zero=3D) at jemalloc_large.c:37:42 frame #13: 0x2ac11342 libc.so.7`__je_large_malloc(tsdn=3D0x2adf90a0, = arena=3D0x2b000500, usize=3D163840, zero=3D) at = jemalloc_large.c:17:9 frame #14: 0x2abed45e = libc.so.7`__je_arena_malloc_hard(tsdn=3D0x2adf90a0, arena=3D,= size=3D131576, ind=3D49, zero=3D) at = jemalloc_arena.c:1205:9 frame #15: 0x2abe1cb0 libc.so.7`iallocztm [inlined] = arena_malloc(tsdn=3D, arena=3D, = size=3D, ind=3D, zero=3D, = tcache=3D, slow_path=3D) at = arena_inlines_b.h:0 frame #16: 0x2abe1c52 libc.so.7`iallocztm(tsdn=3D, = size=3D, ind=3D49, zero=3D, tcache=3D0x2adf92f0,= is_internal=3D, arena=3D0x00000000, = slow_path=3D) at jemalloc_internal_inlines_c.h:55:8 frame #17: 0x2abe7179 libc.so.7`imalloc_body [inlined] = imalloc_no_sample(sopts=3D0xffff946c, dopts=3D0xffff944c, = tsd=3D0x2adf90a0, size=3D131576, usize=3D163840, ind=3D49) at = jemalloc_jemalloc.c:2402:9 frame #18: 0x2abe7106 libc.so.7`imalloc_body(sopts=3D, = dopts=3D, tsd=3D0x2adf90a0) at jemalloc_jemalloc.c:2577:16 frame #19: 0x2abdae88 libc.so.7`imalloc(sopts=3D, = dopts=3D) at tsd.h:0:2 frame #20: 0x2abdaddc libc.so.7`__je_malloc_default(size=3D131576) = at jemalloc_jemalloc.c:2726:2 frame #21: 0x2abdb27f libc.so.7`__malloc [inlined] = imalloc_fastpath(size=3D131576, fallback_alloc=3D) at = jemalloc_internal_inlines_c.h:0:2 frame #22: 0x2abdb149 libc.so.7`__malloc(size=3D131576) at = jemalloc_jemalloc.c:2750:9 frame #23: 0x28aa2b52 libprivatellvm.so.19`::mallocForGrow() = [inlined] safe_malloc at MemAlloc.h:26:18 frame #24: 0x28aa2b4c libprivatellvm.so.19`::mallocForGrow() at = SmallVector.cpp:130:19 frame #25: 0x2798f6dd libprivatellvm.so.19`::grow() [inlined] = mallocForGrow at SmallVector.h:458:48 frame #26: 0x2798f6c9 libprivatellvm.so.19`::grow() at = SmallVector.h:449:16 frame #27: 0x2798fa76 libprivatellvm.so.19`::resize() [inlined] = reserveForParamAndGetAddressImpl, llvm::MachineOperand *>, false> > at = SmallVector.h:257:11 frame #28: 0x2798fa5c libprivatellvm.so.19`::resize() [inlined] = reserveForParamAndGetAddress at SmallVector.h:392:12 frame #29: 0x2798fa5c libprivatellvm.so.19`::resize() [inlined] = append at SmallVector.h:707:29 frame #30: 0x2798fa5c libprivatellvm.so.19`::resize() at = SmallVector.h:674:11 frame #31: 0x2798c39e libprivatellvm.so.19`::createVirtualRegister() = [inlined] resize at IndexedMap.h:62:16 frame #32: 0x2798c393 libprivatellvm.so.19`::createVirtualRegister() = [inlined] grow at IndexedMap.h:72:9 frame #33: 0x2798c390 libprivatellvm.so.19`::createVirtualRegister() = [inlined] createIncompleteVirtualRegister at = MachineRegisterInfo.cpp:149:12 frame #34: 0x2798c38d libprivatellvm.so.19`::createVirtualRegister() = at MachineRegisterInfo.cpp:166:18 frame #35: 0x27c07b5f libprivatellvm.so.19`::EmitCopyFromReg() at = InstrEmitter.cpp:173:19 frame #36: 0x27c0e366 libprivatellvm.so.19`::EmitSpecialNode() at = InstrEmitter.cpp:1278:5 frame #37: 0x27d2707e libprivatellvm.so.19`::operator()() [inlined] = EmitNode at InstrEmitter.h:147:7 frame #38: 0x27d27064 libprivatellvm.so.19`::operator()() at = ScheduleDAGSDNodes.cpp:874:13 frame #39: 0x27d266c1 libprivatellvm.so.19`::EmitSchedule() at = ScheduleDAGSDNodes.cpp:961:9 frame #40: 0x27e0ad27 libprivatellvm.so.19`::CodeGenAndEmitDAG() at = SelectionDAGISel.cpp:1126:42 frame #41: 0x27e08f06 libprivatellvm.so.19`::SelectBasicBlock() at = SelectionDAGISel.cpp:850:3 frame #42: 0x27e08310 libprivatellvm.so.19`::SelectAllBasicBlocks() = at SelectionDAGISel.cpp:1863:7 frame #43: 0x27e056de libprivatellvm.so.19`::runOnMachineFunction() = at SelectionDAGISel.cpp:631:3 frame #44: 0x2964affa libprivatellvm.so.19`::runOnMachineFunction() = at X86ISelDAGToDAG.cpp:190:32 frame #45: 0x27e0377d libprivatellvm.so.19`::runOnMachineFunction() = at SelectionDAGISel.cpp:374:20 frame #46: 0x278de5f1 libprivatellvm.so.19`::runOnFunction() at = MachineFunctionPass.cpp:94:13 frame #47: 0x283716f2 libprivatellvm.so.19`::runOnFunction() at = LegacyPassManager.cpp:1440:27 frame #48: 0x28378063 libprivatellvm.so.19`::runOnModule() at = LegacyPassManager.cpp:1486:16 frame #49: 0x28371ee4 libprivatellvm.so.19`::run() [inlined] = runOnModule at LegacyPassManager.cpp:1555:27 frame #50: 0x28371b90 libprivatellvm.so.19`::run() at = LegacyPassManager.cpp:541:44 frame #51: 0x283784ee = libprivatellvm.so.19`llvm::legacy::PassManager::run(llvm::Module&) at = LegacyPassManager.cpp:1682:14 frame #52: 0x228e059a libprivateclang.so.19`::EmitBackendOutput() = [inlined] RunCodegenPipeline at BackendUtil.cpp:1157:19 frame #53: 0x228e0589 libprivateclang.so.19`::EmitBackendOutput() = [inlined] EmitAssembly at BackendUtil.cpp:1180:3 frame #54: 0x228e0589 libprivateclang.so.19`::EmitBackendOutput() at = BackendUtil.cpp:1341:13 frame #55: 0x22d84b4d = libprivateclang.so.19`::HandleTranslationUnit() at = CodeGenAction.cpp:354:3 frame #56: 0x234f63bd libprivateclang.so.19`::ParseAST() at = ParseAST.cpp:184:13 frame #57: 0x2335bdef libprivateclang.so.19`::ExecuteAction() at = FrontendAction.cpp:1192:3 frame #58: 0x22d8ad1d libprivateclang.so.19`::ExecuteAction() at = CodeGenAction.cpp:1144:30 frame #59: 0x2335b650 libprivateclang.so.19`::Execute() at = FrontendAction.cpp:1078:8 frame #60: 0x232bc3ac libprivateclang.so.19`::ExecuteAction() at = CompilerInstance.cpp:1061:33 frame #61: 0x233f3b7c = libprivateclang.so.19`::ExecuteCompilerInvocation() at = ExecuteCompilerInvocation.cpp:280:25 frame #62: 0x0040df8f c++`::cc1_main() at cc1_main.cpp:284:15 frame #63: 0x0041c927 c++`::ExecuteCC1Tool() at driver.cpp:215:12 frame #64: 0x22f460a6 libprivateclang.so.19`::callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>() = [inlined] operator() at STLFunctionalExtras.h:68:12 frame #65: 0x22f46097 libprivateclang.so.19`::callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>() = [inlined] operator() at Job.cpp:440:34 frame #66: 0x22f46094 libprivateclang.so.19`::callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>() at = STLFunctionalExtras.h:45:12 frame #67: 0x28a3f834 libprivatellvm.so.19`::RunSafely() [inlined] = operator() at STLFunctionalExtras.h:68:12 frame #68: 0x28a3f82f libprivatellvm.so.19`::RunSafely() at = CrashRecoveryContext.cpp:426:3 frame #69: 0x22f456d4 libprivateclang.so.19`::Execute() at = Job.cpp:440:12 frame #70: 0x22f00688 libprivateclang.so.19`::ExecuteCommand() at = Compilation.cpp:199:15 frame #71: 0x22f0097e libprivateclang.so.19`::ExecuteJobs() at = Compilation.cpp:253:19 frame #72: 0x22f21e9c libprivateclang.so.19`::ExecuteCompilation() = at Driver.cpp:1943:5 frame #73: 0x0041bfdd c++`::clang_main() at driver.cpp:391:21 frame #74: 0x0041a387 c++`main at clang-driver.cpp:17:10 frame #75: 0x2aaf8820 libc.so.7`__libc_start1(argc=3D71, = argv=3D0xffffc2a4, env=3D0xffffc3c4, cleanup=3D(ld-elf.so.1`rtld_nop_exit = at rtld.c:3602), mainX=3D(c++`main at clang-driver.cpp:15)) at = libc_start1.c:180:7 frame #76: 0x0040c438 c++`_start at crt1_s.S:84 (I have rarely used lldb. So its commands are not generally familiar.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 21 18:29:36 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 4dCkKJ5T0Wz6HZ3Q for ; Fri, 21 Nov 2025 18:29:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4dCkKH5y5rz3S3H for ; Fri, 21 Nov 2025 18:29:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=g0h7BcLQ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763749788; bh=IbCbGLmLTnZNLWBbnt4pdTFqGkcmo6pKb6V//wCIEb8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=g0h7BcLQBtye22xpdYFB9ALIDVgdIo8ry42HGeylYfyYGACOSeaPbUjXOAKoa8Btr95zWF5djCjHYdMtXLKyAdqMsGC2Rebtx/gc1ZaIWRlyB2YIMzFovC0AqHHIpTzsTe0NxjNkg/T6RhP9htLj7P5KJCWeCTlM4kCa4z1x3rqymGgSwP3UWZCKvBKyYj7hVdx6jeziURpZlMZmr1g6fLw3RJwLxtsByOrVrGM6GH/4xI/evUySqr1bCXaDgtYSCj+JF+s1DXdDYWVdjJacDoVK06mFL/yVfn+iM7cKc2AY/oVAYiDxue6OULwFP4hGBp5SwwWFPKipGHhST1V4+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763749788; bh=ugvpv7/tO/ofSUIWdJopg0EAQOc0+Y1MsxaPb+BJFW7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HnHZNLtA+5aVfwszQxVPOq75bffdLsJtjPH2lfoVzunwKJ7+Xvnrf2/F1e1QT6z6hINWKhbIpO5mBhVF8S/Fe58bxxZIyBRE1Im2eIDtteonEAMmyX3OAyiLT+L2VfpqE3hyynRWTLBuuVKH1LOzTUBYQ54AKro/VtWK5fbchTJOmhr4Wnma5Qy5OMErUZ4RmQ2V//ZXTx53kHonMf0rBfbm3t7ib97jcwgYvMWx6lSmImaMRpeCLZlzYfqrU849rheSM8ZGnVkHk8BVDIoFvdEVsBReasqrQHtBGkX1umVbBrfa9MRE7leadUSULcZXDhK37/CYL/OrlSMhMFWfsg== X-YMail-OSG: 2HQoRmMVM1kfq9eHsgT2IQiDd9ct53hwrlCofrrZRyxtt_TE947bLxVVwM8rWVf zax4iLI6aOKTnU5fphmDQ3Iy87Q6VzSU.cuxG8tY8wwRrDJxn2fXHCAqNnqCpGp0ZKZQCTe8OQAj p8hcxLp4CJYzIOSvj7CukADSXitMmXPJT3y_SlY6zC_QYp8jwgaZDFUinAq6LIaP33bKar0J4hGY 2g7FuFSu_WlELACaB8DIW5Y8ON7GdTna0WZc_AcZ6M7ZjwLj3CvsMg7XdjaPqgjP2ow8A_c4zxL3 CTAg78Df9ybc6J2jZxyeQlnXTaOxYQ_rSb.lu5ghJXv.8oCeoSwFG8Q1IRvWfeaYuX949in4ljHg 9TQK7zLI3HPfmO1gvxloWOZz0Ji0RyXRDA_3f27Q2AKULu9nE0Qod5zSy1zEFUZhFWDB9LRZ6yse RT3QC2EOjY8whyNjN9sCsMmFKwT1Ph6LGx3Ar6oQIDSOvHM5nCIL3Ras0CKJWL9dPFSOqIFA7nct xOO8rv0YNt9cg1dwaoGu22YB8HYsoZwM1Ztm_xgjq_7zF0Wp6CIlliqDLqq7KAU2xq9hU81x34jq LfJnC7ZNPc_lIPIWjflIZewZxk0wm_f7SURBKkcUPvVBirwn2h6Q42aY7lVlghmlphIR9.9yPj7o .SUyAAKW99.OuLwkLaJCo.xTYdFXV5sKZXk9hV8W5_FbSOb3wI6YYDMCLHQl5yE9gSG4AF9pGddg tFKZB2_zCecyCUi.2x8jWF5x_zVdRbPftXmPjLAINey32bQuAqbJLsAOZ6pNHOeh65jr.ebpoleM AOGhsgNHV_Hl9UBG1Lr49uQ7BXvYEQmUYMk4KlcVhMDXCD0eXlS4NtpH6B6a5erxC1kUJXbXV4NY kEevSx76CnI37.ko6lLnDDK4rszgtjGO4lYEGDa1ENjLeMFOyV1vwDqfBLIr6cxDgJhuYMHs2WXM aXA8SZXN8bq8QYYDHu_IYvDwkDMSuvVA7xes61J9b55Ki1wLCNG84K8msUtMUxejQ6mIu3eOzV6r 3lDAYqisCOmuCu_WHgpiOIu7z.yi42xfL9YhPVPIpAyvvPfcBUeBYOfr2C5hMBPamlO_kxNaXCpZ feTf0HWSXAge88vUgEusSyEJBcsfKljWvNQDKDNh6w7.Rkg.f0ofuSRtN3mzSssEh2Gf7NRnj0Jn Z3aAf0X5T4VaHy3L2dzMDSNQGa_xeVjHU89nNgL9mQEtwfpsDc99TgOBcE9D7FDyLcpw3Az4OR7o YYQ44ONblwv910SLW7zSaOZOsMnWnj63kIhNd33BjgUAD8aSRR_9WVsD2ntLs_SJVYMk5DHfux7P kY4LkCK9pIe7ME1dXPB8j3TX_oU7l5bBLhJyqcGBKcUyMMzX6ySyJd8KA9PQVErkaLmQ0DxDbt6C axhp81KWrjB1bm3oS3bIKrbYd3uOza3mc5q.NFohUgkUwJM77VU4niMhXKct5R0LsOkkZSmPYNCl ZeEv_0aYLvBs0vDHdXMiIoALVJngO4DoGCpephMCrYKFvqzFKMM4ZuEOvhg4DKVHXdCeqkg9Zmwl SOzuOlFQdeW2GcJ9EvdHaeJoBwSGRSAT.ddbOdm_f9lnCLmHsLD8VUBKyEblAxD4ZkWpd.lVfO9e XagkdUAe03I4llHw7pWF_ui7VoWJFFD1cqDV.893axBtVYK794tacqnt9LVlMCdPfYSV.H8cH0fp qYwYBgXzWM8Z04sXRp9mkEpW0d9dWawmrwYwvOf0NSA.4nzYx4qB9biTBMnEB5jEUpD_uK4YSJvL HltP8KgqaIwnzFGWq8cNzjmydZyVHiZqNPYPx6DMj0lfbLPinEpdOISFVUnwjOeYuTjju.Rd6.uV Lf7Xr8Nfy1OMZtjhBlri5oI38q8z03Lc3t1gwkbr_qj0UhDpZFGpmVpQ0R8ibwaljkqcMclgkh96 T0hI4lpRKSJXooc7uJ2kS1.ohz9L0Kp34zt1q1pg_qX6ECI0RkDyuSHwQl3EjeK.zF_uCGG9g1ob B8CAn6yZWYVW4YXTJwaAoNsr3C2ebLug9Xet9mXkzUVSrzKnQf7_n3XWwFJEAaSbGGRgda0dK7Xr UmdVvHvYSHPxiB9krUhczlRBH9gBu41dEYQ73kR7_YL3fnTTEj0l7tC2UvCbbvcqeHoruOXUZfNs 1GdV6l51eU5.MT2bjLIzew134VrlCKxUn8FGfqpYwTzjBH6ooNAYg8vH9qKFj.sYuOy_1iydudy2 NawbcssteI2zXWDmP.g127QNW4YVZEw97nsPepVfX5Y.Zp3mwG3oKPWPP.XUNDYphfDCOzrrqjG_ BYS.8yBf5bVLycpM1uw-- X-Sonic-MF: X-Sonic-ID: 96aa5228-725c-4bab-a65c-99e53e4a8a80 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Nov 2025 18:29:48 +0000 Received: by hermes--production-gq1-fdb64d996-jgmsv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 11529524e8e2820a5869edbf3d791bc6; Fri, 21 Nov 2025 18:29:47 +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" [ *** i386 chroot on amd64 can get the failure on main 16 too *** ] [failed without new kernel check detection] From: Mark Millard In-Reply-To: <5A0EABFD-A84F-444E-B41A-BC2F9584FF99@yahoo.com> Date: Fri, 21 Nov 2025 10:29:36 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: <0542BED0-5446-402C-8924-5EA745B8E51C@yahoo.com> References: <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> <87fra9fd4m.fsf@panix.com> <878qg1f8wz.fsf@panix.com> <265F191D-5400-4A9D-BE99-F060770B5DED@yahoo.com> <32C6B8A3-E390-48C8-8454-753511ADDF57@yahoo.com> <5A0EABFD-A84F-444E-B41A-BC2F9584FF99@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from] X-Rspamd-Queue-Id: 4dCkKH5y5rz3S3H I patched the vintage of /usr/src/ on amd64 that is for the pkgbase vintage that I've been using on the test machines. # sysctl debug.vm_check_pg_zero=3D1 debug.vm_check_pg_zero: 0 -> 1 # env WITH_META_MODE=3D make -j10 buildworld --- buildworld --- . . . Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGBuiltin.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/PatternInit.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/SanitizerMetadata.pi= co Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/SwiftCallingConv.pic= o Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/TargetInfo.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/AArch64.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/AMDGPU.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/ARC.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/ARM.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/AVR.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/BPF.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/CSKY.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Hexagon.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Lanai.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/LoongArch.pi= co Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/M68k.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/MSP430.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Mips.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/NVPTX.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/PNaCl.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/PPC.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/RISCV.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/SPIR.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Sparc.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/SystemZ.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/TCE.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/VE.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/WebAssembly.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/X86.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/XCore.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/VarBypassDetector.pi= co Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CrossTU/CrossTranslationUnit= .pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Action.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Compilation.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Distro.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Driver.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/DriverOptions.pico Building /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Job.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Multilib.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/MultilibBuilder.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/OptionUtils.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Phases.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/SanitizerArgs.pico Building /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Tool.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChain.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AIX.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AMDGPU.pic= o Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AMDGPUOpen= MP.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AVR.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/AArch= 64.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/ARM.p= ico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/CSKY.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/Loong= Arch.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/M68k.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/Mips.= pico : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/PPC.p= ico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/RISCV= .pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/Sparc= .pico Abort trap (core dumped) *** [CodeGen/CGBuiltin.pico] Error code 134 I had also previously tested without enabling debug.vm_check_pg_zero just to check if failures were still happening. It turns out that for my current context that failed building the same .pico file: Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGBuiltin.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGHLSLRuntime.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGLoopInfo.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGNonTrivialStruct.p= ico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjC.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjCGNU.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjCMac.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjCRuntime.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGOpenCLRuntime.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGOpenMPRuntime.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGOpenMPRuntimeGPU.p= ico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGPointerAuth.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGRecordLayoutBuilde= r.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGStmt.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGStmtOpenMP.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGVTT.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGVTables.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenAction.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenFunction.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenModule.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenPGO.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenTBAA.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenTypes.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ConstantInitBuilder.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CoverageMappingGen.p= ico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ItaniumCXXABI.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/LinkInModulesPass.pi= co Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/MacroPPCallbacks.pic= o Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/MicrosoftCXXABI.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ModuleBuilder.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ObjectFilePCHContain= erOperations.pico : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" Abort trap (core dumped) *** [CodeGen/CGBuiltin.pico] Error code 134 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 21 19:08:47 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 4dClB91RlJz6HcfY for ; Fri, 21 Nov 2025 19:08:49 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dClB870Q5z3Xvb; Fri, 21 Nov 2025 19:08:48 +0000 (UTC) (envelope-from mmel@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763752129; 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=Wj7idLNjevG2NGXbFSeizKCDpmztYXzj5ktua28yK98=; b=hVUq20HzGyXfF+BfIUL2xIYjbyWFyQdzsg+XCQN5V72YqYIYlXH8ZMm5MEWWs+a7XYlu1w /SDg/lHrFM4FCwx7FLeC4uCQXG2ONrnzjK5I/YhwrhrmwegaiZzBxmb8TDs0Y1j6XkQNTu BZjzAF2mzTwp8RgHmcXv28anbzkpYIXIXBJnvYTBzKS0YTO3YAE343+xpx4cwgQ1aMmhX6 I3xgJ8aPs7qcNpuTK5F3Aqj3tNj4Gpv0IMkaN7afy9ohZg3Ych/3PysiHG2FnT2i7SCZi3 DBISh51ReuXNQdZs0YK5HOLx3Zobk+8qYa+edUedEp9vmYrsp6AEFkC8jqsByA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763752129; 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=Wj7idLNjevG2NGXbFSeizKCDpmztYXzj5ktua28yK98=; b=QW2ajW8Ys/RQUyqB9bAG7EzzlTa/1UqJznWr7HK4K9al/HrrnDuBKYPO6nWpStrDsMY4XV 4DMIhgJSW+uF+/M06i14z73mfn88wC5V04j+td+k8NP70JqYgYA454Pop7plJ1i6NylrwK A61Agv4LoGMb89fsu3zOIdijhlC0wX4tbAH5Iq1aCgS9mQ5da2XgsRDRiABHNC8W9fT8Fb 9UYkWvjzpvjlx0EGf/U8K9B/Hx5tKINSCKQWNtjMAobM1OYFHJxTvLc0AdQidtTjtrLwjy 5psnKA5QVAjOdTYE/egb1JynNF7rCsXCRUXV88VSWtTXriyoKYkkGZTHijwrkQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763752129; a=rsa-sha256; cv=none; b=vjuALm7LYNlnw90JAhVaiI3zogFt39XiiWRz3frxG+k5GTh1mJswZnvZwn8U8zhHcPtZ+6 FOkTN6h1P8QJLJbBGkyY9g2rdj1lZK9TFLAUNofvrdgYb+XhkTdc/dOaIfHVd3e0U1vJdI vNIQ1CQR8z7h4kyyduh/HzF+QL667KO7zkgzXhqY6yUu4BxOHNkc0OifVpX4FrvMRTQcLw TUG94EMAOC13GPd3Y66J3z2UstyOx8wJEbKfoYE/4IAkUL0y4BhW879/983Pk0esTC/bJB 3rN2jXienE5lg2+gOKYNp76ZYSs8luD62+9fSODPijv+NCsJKxuZ5PLUkWfT4g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (internet-251.radiolinkplus.cz [109.205.241.251]) (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 4dClB83t52z7Hf; Fri, 21 Nov 2025 19:08:48 +0000 (UTC) (envelope-from mmel@freebsd.org) Message-ID: Date: Fri, 21 Nov 2025 20:08:47 +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 From: Michal Meloun Reply-To: mmel@FreeBSD.org Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) To: Konstantin Belousov Cc: FreeBSD Current References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 21.11.2025 10:03, Konstantin Belousov wrote: > On Fri, Nov 21, 2025 at 10:36:42AM +0200, Konstantin Belousov wrote: >> On Fri, Nov 21, 2025 at 08:12:55AM +0100, Michal Meloun wrote: >>> I have confirmed that jmalloc assertions are caused by mmap() failure. It >>> can return non-zeroed page(s) for mmap(MAP_ANON), which is clearly a bug. >>> >>> I have confirmed this on native ARMv7, and according to Mark, it is also >>> reproducible on ARM32 and i386 jails. I think I saw it also on a >>> memory-constrained (4 GB) aarch64, but I cannot reproduce it yet. >>> >>> Have somebody idea how to identify vm faults associated with anon mmap to >>> trigger detection of this failure in kernel? Or any other hint? >> >> I think It would be much more visible if freshly allocated anonymous pages >> are corrupted. A similar mechanism to get zeroed pages is used to get >> fresh page table pages, and corruption there must cause a lot of kernel >> page faults with 'invalid PTE bit' hw reports. >> But of course everything is possible. >> >> VM has an optimization where we track known-to-be-zeroed free page >> separately, by marking them with PG_ZERO flag. If allocation needs a >> zeroed page and the flag is set, we skip calling pmap_zero_page() on it. >> >> Also, in vm_page_free_prep() when we are told that the page is zeroed, >> with DIAGNOSTIC enabled, on amd64 and arm64, we do check for that. >> >> So lets add slow check for vm_fault code that supposedly zeroed page is >> indeed zeroed. Can you try to catch the issue with the patch applied, >> and DIAGNOSTIC enabled? Patch is arch-agnostic and I believe should >> work on armv7, although obviously causing slowdown. > > I also made the vm_page_free_prep() check MI. > Please use https://reviews.freebsd.org/D53850 instead of the previous > patch. Hi Kib, i was unexpectedly out of the office today, so I only got back to debugging a moment ago and couldn't devote much time to it today. First, many thanks for your efforts, but this check doesn't trigger when the problem occurs To be more precise, testing case on fresh kernel(d8bfcacd12aba73188c44a157c707908e275825d) with PMAP_DEBUG defined in pmap-v6.c and with trivial zero check for first page at this place -> https://cgit.freebsd.org/src/tree/contrib/jemalloc/src/pages.c#n281 causes this failure: __je_pages_map: addr: 0x0, ret: 0x3087b000, size: 4096, alignment: 4096, prot: 0x00000003, flags: 0x0C001002 __je_pages_map: i: 0, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 23, p[i]: 0x308E5F94, p: 0x3087b000 __je_pages_map: i: 27, p[i]: 0x308E23F4, p: 0x3087b000 __je_pages_map: i: 29, p[i]: 0x308F077C, p: 0x3087b000 __je_pages_map: i: 30, p[i]: 0x308C3444, p: 0x3087b000 __je_pages_map: i: 33, p[i]: 0x308C57BC, p: 0x3087b000 __je_pages_map: i: 36, p[i]: 0x308E41E4, p: 0x3087b000 __je_pages_map: i: 39, p[i]: 0x308EA2E4, p: 0x3087b000 __je_pages_map: i: 42, p[i]: 0x308EC444, p: 0x3087b000 __je_pages_map: i: 44, p[i]: 0x308EE60C, p: 0x3087b000 __je_pages_map: i: 47, p[i]: 0x308C7AF4, p: 0x3087b000 __je_pages_map: i: 58, p[i]: 0x308C9F24, p: 0x3087b000 __je_pages_map: i: 79, p[i]: 0x308E8114, p: 0x3087b000 __je_pages_map: i: 80, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 160, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 240, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 320, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 400, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 480, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 560, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 640, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 720, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 800, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 880, p[i]: 0xFFFFFFFF, p: 0x3087b000 __je_pages_map: i: 960, p[i]: 0xFFFFFFFF, p: 0x3087b000 The pattern looks interesting; it is not exactly same in all cases, but it is similar. Another example: __je_pages_map: addr: 0x0, ret: 0x32d4d000, size: 4096, alignment: 4096, prot: 0x00000003, flags: 0x0C001002 __je_pages_map: i: 64, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 144, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 224, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 304, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 384, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 408, p[i]: 0x32CE5854, p: 0x32d4d000 __je_pages_map: i: 416, p[i]: 0x32CE5064, p: 0x32d4d000 __je_pages_map: i: 429, p[i]: 0x32CE5BD4, p: 0x32d4d000 __je_pages_map: i: 455, p[i]: 0x32CE5FD4, p: 0x32d4d000 __je_pages_map: i: 464, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 544, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 589, p[i]: 0x32CE6744, p: 0x32d4d000 __je_pages_map: i: 591, p[i]: 0x32CE6B04, p: 0x32d4d000 __je_pages_map: i: 603, p[i]: 0x32CE6EC4, p: 0x32d4d000 __je_pages_map: i: 624, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 704, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 784, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 864, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 944, p[i]: 0xFFFFFFFF, p: 0x32d4d000 __je_pages_map: i: 969, p[i]: 0x40F8917C, p: 0x32d4d000 __je_pages_map: i: 971, p[i]: 0x40EB9F0C, p: 0x32d4d000 __je_pages_map: i: 973, p[i]: 0x40D164CC, p: 0x32d4d000 __je_pages_map: i: 978, p[i]: 0x40F47EFC, p: 0x32d4d000 __je_pages_map: i: 980, p[i]: 0x4116768C, p: 0x32d4d000 __je_pages_map: i: 996, p[i]: 0x3E5430FC, p: 0x32d4d000 __je_pages_map: i: 1002, p[i]: 0x40F88FAC, p: 0x32d4d000 __je_pages_map: i: 1006, p[i]: 0x40D1669C, p: 0x32d4d000 __je_pages_map: i: 1011, p[i]: 0x40F47D2C, p: 0x32d4d000 __je_pages_map: i: 1012, p[i]: 0x3E542F2C, p: 0x32d4d000 __je_pages_map: i: 1021, p[i]: 0x40EB9D3C, p: 0x32d4d000 __je_pages_map: i: 1022, p[i]: 0x4116785C, p: 0x32d4d000 Still searching, Michal From nobody Fri Nov 21 19:34:21 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 4dClm63qtPz6HfRP for ; Fri, 21 Nov 2025 19:34:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4dClm55pVTz3chx for ; Fri, 21 Nov 2025 19:34:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PndL5tnx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763753678; bh=ifdAGf9oo0x/ueZmR9vR1Pws7E6bmoOnE1xgOd7gtb8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PndL5tnxnuahj00HrZIF5KAqhjMII8WtcdouFro5TEh0NbMo7k/qzZL3MmUPGdNUjrtAZ95GikSHM6WoJX1bA2Qkna9YbesrykkSaHYAl8D5+0sQ1zuVXG5xf6RNxj9YAzMdMLJn8WHAW2RRVgb/fK1ZxQ8xS4M8UdvSEYOPWMkEVP0vAYW2nFaWsmCqAzTeFnQ8hqDmJnPQKxDJIpJl8DDj8GL55dT90CwLAIfhcwYUminSoKjCbGCEUQGRWBYl/LVKXW3Bw+uZOg9n6ZB2hfvQqmYUh+Px24VhW0I9/m4RZRZSG57pVbhouk0qvBJwmbXTMPOXh1se3z4hbqwhEQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763753678; bh=IkeohZHbTu/eVBxinqu1XaGY+wn06Z0geqBm+cAwXtL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QtA51Siqx7hklU/Rji0VXT4EG+Qtx9is9EqmdIRTntj03nqD0PYGSk+XfP2PnXi8vwMzRze6UV5JV3JQwikPsW/oMqUfgkdKQCDvdmcFIk+o6mqqKoFbLiPCOSiQFqphTDsqS06trfaIlvCiI7jaapa1NE2vqCY71b4zXtR9UExzkdyutYo3bCVHZsKmlPSD9EcoVexx2IoG8VZabMXokdjm2TyHloVUUE0mhh22oF+rsQERMZGJdOuIsZSoQnZD2pWThm2AYNLlDahJ8Ry4e/DaHOJqtH9wYsEYlr7+b8Rx5SecnF7Bf0gAQP335i0r1kWOfg/iiKB0vq/f3ymZfw== X-YMail-OSG: .ko.ZSoVM1lfT4XB7YiLOy3lNnDTgm6DItbKyMVFxmB5PxQHqTH9GOpf7A5wcsK C_BMT8zVCo5yXjUohIhUHRUGHIp9hvYcICUyfr5w80N9vIDjJ7pp75ieZvgjtc9Gg_uH_xzsRcQw 3Agz4uQEgPWzOcJ8hlE27U3piceyIzDJ_bxgtESe11WCMH9ZbuppqSS0Xe_4RfAjDkhe5ujCoDRt 8PghesqHQDiqL2mgvaoNG3RrYOg5EOHO4ka_czhUWNCj.X7PmQm47JxiFoTKi4Jox64HGzO6aeEN rQqtiaOfF5WnWhNxwSX_h7DnEQA_CUR4S.h1mKplB1oeEgoT1byN_IHnX5WKGyTljw52yPYFwlGe NLDetPA9QOQKThoLQDLqub0fzltOM2mow7D7exG4f.EPNY_dTZUh4zJhCz32fQf3.9oUA0M2oZlh n2kbD9W4EW8fVqUwL2KlBwFuE53bn1yyTN1yTn_xudxo4fHAXmnSAm4UeWBjLOtgTEM9pAz0oiU_ Y9_6sAw.GQ7ltM3Qu_YbiPl1oIJcFIVpvYx2wjZ1VEbjlUGp5poOlHDAXRkcRRQ3ACMC5inIk6ys wADW568KA1WRjj.ADT1Y76Y0NNPPzrVX8Hk4boHUJkG.us6Fo38AlmhPNbCtRw4aaQy0e1mxfxhN X_IygwNZSBpvkNoFnkzSPm_LbQbN9nrNnpykmQAlh3UtsRMriLYykVWIAN3f7b7l6dz2lbIVZ.Zn ytuJ8JiHgjfjIIcWBU.TkdKhGze2wyvIjByAqNl8E5mKWMTvb0h3eLJZbWk5.lXQ6UEfP4v2mvrM gxYsSrVpwCfVKS2U2ifmBKCt.Lzm15aRvCPaRo5e0P8Uy4fHpzqNMHWcgAOjzlxe4onQ__eJ9Z.k HceiVXs22WsILHIC82vkJZPn62ciWjAl9tgTo58AWzTVcR0rcxkSjERIieNqRj0fgONOaSPJJS_L 5lq26R9RPbbTtFVGE_FiELOTeljRifdwQ6VS5fuPH73sZRP_cf.aoQ7XiQMN1BLbOMnDYEEJXYMt jZMZ7dx_vAWo0iLC6pS9WCT_EUEGui0MsR4RuZNFnUgaZtzZlYZljr8feyA6RTkCjPO7AXjuWIbR 8dBTYXNEmg6_FMiRUiBpdgrdkh9tVzHbScC0GSGTbKk1iBoiVvz.wGwzWXSST7tFOZ2k9pKMI1r4 q3ld4U9Ak.XBD4_esCzzwn_ULdmvslMVvQq90plIk5b5NfmFNNrtymV3sCKYfKP51GVZX7_rbrN. C9V.u7teZgurEzhWHVHeVOJZ8pqJslHsXpd7tQtUwgsmKWGW67CuHNEXq6D19GMhXUkjC.mw0Ci0 8b9Q4DTupvzWTGvpiXUzvROQyTNpNFpP.UrpPWQRI_Ee4rMP9ZymmqNoxHJc7_cAegNxvNDG46iJ PAH1cO3QQbQ1dwG2JsjFwy.mLv6M3jc9IDu9fydnKKho6xyb188xl1g9nUHav3pSRXUi_DLNXX73 8OjkqcStyrtJm7gciSjAoce7.4IOgF8DyycxoSLTQpapACe0HhWIlNiYibg6LcMjWNFUzaT1AFow fa_Ai68UN16uaTyuCSOf1eh5pAHyVJyS4wmzIUGkO1Xsaf7eVil3fUapW9sP6oYlzRMOFTIx1xFe kvhdkwyA866ApkbgUcYKTg0lhOiuBgQ1lDi8WjaTLGV6ECT3HEIGjcAEeKKfu4XSwXV9HWcMFdqL jF_A1COycueDdtVv9Qdina3fz9HKRdAMG0BHVYQptOEEugPlwU2196ZzJrSf.JtlTOwdgwVzF3Jn EIG7NMmNJcBvZDwdKbjpWywCCCm5x1f5QxOQe36F.mFHd252FriFXB3WA4VsHQ1RG2anogeMdpcj 2HH0BuSvkK3BOw7xUsMZW2dmZFpU2nnnZNhhwtP3RGDODrug8klpDP_.QLR_aBrsKLdc7BGKt6Sb UFL_Auyu1oC4rdFkgqhKOoX5B4KzCCjgYPPntKCDwgOdX_.f_RiYBUsYyT6twn6gAaiNXynSncK1 MiS3EkiJR2oUdR3k6Hp_8AOpbYc6NcvywPdpDPxEjv6FaxyJovyXviq7_4WeQ7ce5ClSEl1P94d3 kp8nL1MYhTDaGXNeOHMk2FP69vQBCdXv9rB3iBUbNK6ZKp9j_y5v3uXOLmRRpyVPt6byunTcXn7z O3v1aadvPx2xVpmDuoLQ.I6CICot87jG8Qc3I7kJnS9eY62UHsoGasiotYnjbV8RiMtkLA2_wbzH VkGfR9xbLeqOeWH_YAOF0_VV9SiYz1DZqzK8igq7dYNS_a9OhwItruqFPwCMi_njEFPpObZyj4GV dERdRM50lZvqNRSKB5YW7 X-Sonic-MF: X-Sonic-ID: c1e64a8b-e850-4f19-ad3c-76e92cadb741 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Nov 2025 19:34:38 +0000 Received: by hermes--production-gq1-fdb64d996-8wjqq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7bf2fdc6965f3f1828bb041d5eb5a307; Fri, 21 Nov 2025 19:34:33 +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" [ *** i386 chroot on amd64 can get the failure on main 16 too *** ] [failed without new kernel check detection] From: Mark Millard In-Reply-To: <0542BED0-5446-402C-8924-5EA745B8E51C@yahoo.com> Date: Fri, 21 Nov 2025 11:34:21 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: quoted-printable Message-Id: References: <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> <87fra9fd4m.fsf@panix.com> <878qg1f8wz.fsf@panix.com> <265F191D-5400-4A9D-BE99-F060770B5DED@yahoo.com> <32C6B8A3-E390-48C8-8454-753511ADDF57@yahoo.com> <5A0EABFD-A84F-444E-B41A-BC2F9584FF99@yahoo.com> <0542BED0-5446-402C-8924-5EA745B8E51C@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.934]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from] X-Rspamd-Queue-Id: 4dClm55pVTz3chx On Nov 21, 2025, at 10:29, Mark Millard wrote: > I patched the vintage of /usr/src/ on amd64 that is for > the pkgbase vintage that I've been using on the test > machines. >=20 > # sysctl debug.vm_check_pg_zero=3D1 > debug.vm_check_pg_zero: 0 -> 1 >=20 > # env WITH_META_MODE=3D make -j10 buildworld > --- buildworld --- > . . . > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGBuiltin.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/PatternInit.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/SanitizerMetadata.pi= co > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/SwiftCallingConv.pic= o > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/TargetInfo.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/AArch64.pico= > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/AMDGPU.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/ARC.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/ARM.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/AVR.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/BPF.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/CSKY.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Hexagon.pico= > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Lanai.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/LoongArch.pi= co > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/M68k.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/MSP430.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Mips.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/NVPTX.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/PNaCl.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/PPC.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/RISCV.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/SPIR.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/Sparc.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/SystemZ.pico= > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/TCE.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/VE.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/WebAssembly.= pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/X86.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/Targets/XCore.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/VarBypassDetector.pi= co > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CrossTU/CrossTranslationUnit= .pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Action.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Compilation.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Distro.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Driver.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/DriverOptions.pico > Building /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Job.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Multilib.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/MultilibBuilder.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/OptionUtils.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Phases.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/SanitizerArgs.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/Tool.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChain.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AIX.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AMDGPU.pic= o > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AMDGPUOpen= MP.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/AVR.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/AArch= 64.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/ARM.p= ico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/CSKY.= pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/Loong= Arch.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/M68k.= pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/Mips.= pico > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/PPC.p= ico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/RISCV= .pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Driver/ToolChains/Arch/Sparc= .pico > Abort trap (core dumped) > *** [CodeGen/CGBuiltin.pico] Error code 134 >=20 >=20 >=20 > I had also previously tested without enabling debug.vm_check_pg_zero > just to check if failures were still happening. It turns out that > for my current context that failed building the same .pico file: >=20 > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGBuiltin.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGHLSLRuntime.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGLoopInfo.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGNonTrivialStruct.p= ico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjC.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjCGNU.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjCMac.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGObjCRuntime.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGOpenCLRuntime.pico= > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGOpenMPRuntime.pico= > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGOpenMPRuntimeGPU.p= ico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGPointerAuth.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGRecordLayoutBuilde= r.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGStmt.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGStmtOpenMP.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGVTT.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CGVTables.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenAction.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenFunction.pico= > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenModule.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenPGO.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenTBAA.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CodeGenTypes.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ConstantInitBuilder.= pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/CoverageMappingGen.p= ico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ItaniumCXXABI.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/LinkInModulesPass.pi= co > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/MacroPPCallbacks.pic= o > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/MicrosoftCXXABI.pico= > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ModuleBuilder.pico > Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/CodeGen/ObjectFilePCHContain= erOperations.pico > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" > Abort trap (core dumped) > *** [CodeGen/CGBuiltin.pico] Error code 134 >=20 >=20 It turns out that frames #0..#31 have bt text that match. So just in case that much of a sometimes common context might help in some way: (lldb) bt * thread #1, name =3D 'c++', stop reason =3D signal SIGABRT * frame #0: 0x24bd378b libsys.so.7`__sys_thr_kill at thr_kill.S:4 frame #1: 0x2ab2231b libc.so.7`__raise(s=3D6) at raise.c:48:10 frame #2: 0x2abcc73b libc.so.7`abort at abort.c:61:8 frame #3: 0x2ac10440 = libc.so.7`ehooks_debug_zero_check(addr=3D, = size=3D) at ehooks.h:0 frame #4: 0x2ac0ccfa libc.so.7`__je_extent_alloc_wrapper [inlined] = ehooks_alloc(tsdn=3D, ehooks=3D, = new_addr=3D, size=3D, alignment=3D,= zero=3D0xffff9977, commit=3D) at ehooks.h:208:3 frame #5: 0x2ac0cc5a = libc.so.7`__je_extent_alloc_wrapper(tsdn=3D0x2adf90a0, pac=3D0x2b0015e4, = ehooks=3D0x2b000080, new_addr=3D0x00000000, size=3D28672, = alignment=3D4096, zero=3Dtrue, commit=3D0xffff99df, = growing_retained=3D) at jemalloc_extent.c:1003:15 frame #6: 0x2ac0c58e = libc.so.7`__je_ecache_alloc_grow(tsdn=3D0x2adf90a0, pac=3D0x2b0015e4, = ehooks=3D0x2b000080, ecache=3D0x2b0036d0, expand_edata=3D0x00000000, = size=3D28672, alignment=3D4096, zero=3D, = guarded=3D) at jemalloc_extent.c:126:11 frame #7: 0x2ac3c73f libc.so.7`pac_alloc_impl [inlined] = pac_alloc_real(tsdn=3D, pac=3D, = ehooks=3D, size=3D, alignment=3D4096, = zero=3D, guarded=3D) at jemalloc_pac.c:124:11 frame #8: 0x2ac3c696 libc.so.7`pac_alloc_impl(tsdn=3D0x2adf90a0, = self=3D0x2b0015e4, size=3D28672, alignment=3D4096, zero=3D, = guarded=3D, frequent_reuse=3D, = deferred_work_generated=3D) at jemalloc_pac.c:178:11 frame #9: 0x2ac3afe0 libc.so.7`__je_pa_alloc [inlined] = pai_alloc(tsdn=3D, self=3D, = size=3D, alignment=3D, zero=3D, = guarded=3D, frequent_reuse=3D, = deferred_work_generated=3D) at pai.h:43:9 frame #10: 0x2ac3afc9 libc.so.7`__je_pa_alloc(tsdn=3D0x2adf90a0, = shard=3D0x2b0015d8, size=3D28672, alignment=3D4096, slab=3D, = szind=3D19, zero=3D, guarded=3D, = deferred_work_generated=3D0xffff9ac3) at jemalloc_pa.c:139:11 frame #11: 0x2abec82b libc.so.7`arena_slab_alloc(tsdn=3D,= arena=3D, binind=3D19, binshard=3D0, bin_info=3D0x2ac71538) = at jemalloc_arena.c:839:18 frame #12: 0x2abebdaa = libc.so.7`__je_arena_cache_bin_fill_small(tsdn=3D0x2adf90a0, = arena=3D0x2b000500, cache_bin=3D0x2adf9470, cache_bin_info=3D0x2b0004a6, = binind=3D19, nfill=3D32) at jemalloc_arena.c:1034:16 frame #13: 0x2ac2b737 = libc.so.7`__je_tcache_alloc_small_hard(tsdn=3D0x2adf90a0, = arena=3D0x2b000500, tcache=3D0x2adf92f0, cache_bin=3D0x2adf9470, = binind=3D19, tcache_success=3D0xffff9b87) at jemalloc_tcache.c:238:2 frame #14: 0x2abe1d81 libc.so.7`iallocztm [inlined] = tcache_alloc_small(tsd=3D, arena=3D0x2b000500, = tcache=3D, size=3D, binind=3D, = zero=3D, slow_path=3D) at = tcache_inlines.h:68:9 frame #15: 0x2abe1cd7 libc.so.7`iallocztm [inlined] = arena_malloc(tsdn=3D, arena=3D, = size=3D, ind=3D, zero=3D, = tcache=3D, slow_path=3D) at = arena_inlines_b.h:151:11 frame #16: 0x2abe1c52 libc.so.7`iallocztm(tsdn=3D, = size=3D, ind=3D19, zero=3D, tcache=3D0x2adf92f0,= is_internal=3D, arena=3D0x00000000, = slow_path=3D) at jemalloc_internal_inlines_c.h:55:8 frame #17: 0x2abe7179 libc.so.7`imalloc_body [inlined] = imalloc_no_sample(sopts=3D0xffff9c3c, dopts=3D0xffff9c1c, = tsd=3D0x2adf90a0, size=3D864, usize=3D896, ind=3D19) at = jemalloc_jemalloc.c:2402:9 frame #18: 0x2abe7106 libc.so.7`imalloc_body(sopts=3D, = dopts=3D, tsd=3D0x2adf90a0) at jemalloc_jemalloc.c:2577:16 frame #19: 0x2abdae88 libc.so.7`imalloc(sopts=3D, = dopts=3D) at tsd.h:0:2 frame #20: 0x2abdaddc libc.so.7`__je_malloc_default(size=3D864) at = jemalloc_jemalloc.c:2726:2 frame #21: 0x2abdb27f libc.so.7`__malloc [inlined] = imalloc_fastpath(size=3D864, fallback_alloc=3D) at = jemalloc_internal_inlines_c.h:0:2 frame #22: 0x2abdb149 libc.so.7`__malloc(size=3D864) at = jemalloc_jemalloc.c:2750:9 frame #23: 0x28aa2cce libprivatellvm.so.19`::grow_pod() [inlined] = safe_malloc at MemAlloc.h:26:18 frame #24: 0x28aa2cc8 libprivatellvm.so.19`::grow_pod() at = SmallVector.cpp:143:15 frame #25: 0x22004f24 libprivateclang.so.19`::resize() [inlined] = grow_pod at SmallVector.h:152:11 frame #26: 0x22004f14 libprivateclang.so.19`::resize() [inlined] = grow at SmallVector.h:539:41 frame #27: 0x22004f14 libprivateclang.so.19`::resize() [inlined] = reserveForParamAndGetAddressImpl > at SmallVector.h:257:11 frame #28: 0x22004f14 libprivateclang.so.19`::resize() [inlined] = reserveForParamAndGetAddress at SmallVector.h:551:9 frame #29: 0x22004f14 libprivateclang.so.19`::resize() [inlined] = append at SmallVector.h:707:29 frame #30: 0x22004f14 libprivateclang.so.19`::resize() at = SmallVector.h:674:11 frame #31: 0x22004de0 libprivateclang.so.19`::resize() at = BitVector.h:344:10 . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 21 19:54:18 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 4dCmBt6cMjz6HgRF for ; Fri, 21 Nov 2025 19:54:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCmBt3R64z3hth; Fri, 21 Nov 2025 19:54:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5ALJsIdr050665; Fri, 21 Nov 2025 21:54:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5ALJsIdr050665 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5ALJsIA8050664; Fri, 21 Nov 2025 21:54:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Nov 2025 21:54:18 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> 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: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dCmBt3R64z3hth On Fri, Nov 21, 2025 at 08:08:47PM +0100, Michal Meloun wrote: > First, many thanks for your efforts, but this check doesn't trigger when the > problem occurs > Hm, ok. This is a data point, in fact. > > To be more precise, testing case > on fresh kernel(d8bfcacd12aba73188c44a157c707908e275825d) > with PMAP_DEBUG defined in pmap-v6.c and with > trivial zero check for first page at this place -> > https://cgit.freebsd.org/src/tree/contrib/jemalloc/src/pages.c#n281 > > causes this failure: > > __je_pages_map: addr: 0x0, ret: 0x3087b000, size: 4096, alignment: 4096, > prot: 0x00000003, flags: 0x0C001002 > __je_pages_map: i: 0, p[i]: 0xFFFFFFFF, p: 0x3087b000 > __je_pages_map: i: 23, p[i]: 0x308E5F94, p: 0x3087b000 Could you, please, when the failure is detected, spawn 'procstat -v ' and dump the memory map of the process? To be clear, I want to see all of this: - the address of the mapping returned by mmap - its size - the location of the first non-zero byte - memory map From nobody Fri Nov 21 20:02:57 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 4dCmNn0lQGz6Hh9G for ; Fri, 21 Nov 2025 20:03:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCmNl5j7fz3l83; Fri, 21 Nov 2025 20:03:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5ALK2vd4051087; Fri, 21 Nov 2025 22:03:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5ALK2vd4051087 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5ALK2v95051086; Fri, 21 Nov 2025 22:02:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Nov 2025 22:02:57 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> 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: X-Spamd-Bar: / X-Spamd-Result: default: False [0.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.995]; NEURAL_SPAM_SHORT(0.70)[0.699]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4dCmNl5j7fz3l83 On Fri, Nov 21, 2025 at 09:54:23PM +0200, Konstantin Belousov wrote: > On Fri, Nov 21, 2025 at 08:08:47PM +0100, Michal Meloun wrote: > > First, many thanks for your efforts, but this check doesn't trigger when the > > problem occurs > > > Hm, ok. This is a data point, in fact. > > > > > To be more precise, testing case > > on fresh kernel(d8bfcacd12aba73188c44a157c707908e275825d) > > with PMAP_DEBUG defined in pmap-v6.c and with > > trivial zero check for first page at this place -> > > https://cgit.freebsd.org/src/tree/contrib/jemalloc/src/pages.c#n281 > > > > causes this failure: > > > > __je_pages_map: addr: 0x0, ret: 0x3087b000, size: 4096, alignment: 4096, > > prot: 0x00000003, flags: 0x0C001002 > > __je_pages_map: i: 0, p[i]: 0xFFFFFFFF, p: 0x3087b000 > > __je_pages_map: i: 23, p[i]: 0x308E5F94, p: 0x3087b000 > > Could you, please, when the failure is detected, spawn 'procstat -v ' > and dump the memory map of the process? To be clear, I want to see all > of this: > - the address of the mapping returned by mmap > - its size > - the location of the first non-zero byte > - memory map Also, regardless of the output above, please try this as a wild guess: diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 5b4517d2bf0c..5c6ed51706bf 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -2222,7 +2222,7 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, * Remove any pages that may still be in the object from a previous * deallocation. */ - if (next_pindex < prev_object->size) { + if (true || next_pindex < prev_object->size) { vm_object_page_remove(prev_object, next_pindex, next_pindex + next_size, 0); #if 0 From nobody Fri Nov 21 20:52:29 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 4dCnTq4f13z6HlGs for ; Fri, 21 Nov 2025 20:52:31 +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 4dCnTq130wz3tMJ; Fri, 21 Nov 2025 20:52:31 +0000 (UTC) (envelope-from mmel@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763758351; 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=MhQsteH2W899otZQmUW6bBAOJx1+djyom1hmn2YnjDw=; b=ogUQtQ3n1rjukrHKZndkMyeDVl1rKZd9ORXatn5qZNhjhZOOLSgprfMIHJkRFvDL6/UE5D eX9BbIItxZ+U9jXBoM91bN+dhct9AEkBBC7YMIsl294wes8EGIDYW03W4LcYeflilVPdgK //sG9Xc90yjZpxGsAc679ecu68HnIWShTCgOMoNGpD0GdPdScZraXNbocJIaSoyUBXfy4q rUIEdOtWv8AA8MMpsVhYGDGUzUghMGFzC3mnuTuQJgvFIy8W8ljfD14Mne9/6Frs9t1/nN BgOJOkqQhs56S0NYGhkeQlnGWJf7yWauXT+KuoJE84xECDKyCLIk+HNtbr5VeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763758351; 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=MhQsteH2W899otZQmUW6bBAOJx1+djyom1hmn2YnjDw=; b=n4dqAAAJL9bV8KHlZDyeOZnAZrumdcIPttn6MHSojhABprlvdlYunCcMrBd1g/C60tuPwK EJ4g0M1SKU+NcD522ANemNs49HVoKNVwcKtD1FdI/0yYREI4Rgbz/sxk2M7/I4gwdYZ15d 4KNA2SkptTyUQtdbt/fFWqf2Rca6hBIH90rYtxIMNd3JNlwAPsRQ4lDPo9MUPrDL1rqvTJ sAdXS31mDW0lAtWQV5I/0wkfvTEc2vZWoD0DL3DX7U7W0y/l9yAcdHt+Bxc0SmsKh/GGJ2 ANck4Kd20gv/jHR6VKe8ziOZIjZjARY3WBvc5RoetE3njAKWaOWSotYE/GtwAg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763758351; a=rsa-sha256; cv=none; b=aGvkOdACK1KuySoSwdiNELMA7np9Ms6zXYW7PfRNrVE+J+QtPT4HJxAf1m+w2hiwrLkYYW 6qGmZNV+nENqfk1aN+aZbTDu8AnyqMG7tHx704B29GyGAoBDOg05uqHu9Z7nJ3vaz9y8Uh Rv2H4FIMzdZsPjOqC+MD2mmvpxoo2DEuCvrEwHcCXnaOmXQW4QgV7QnqBrXnXQ0Jrwl1h0 mxcF/jRVdXzpXlIrurNM9n+fkzC4feGNbYiiHRpRPKMhDTRMzlV2zURlMpNz+LUztgcCM1 wAG75Avw5eTr80BIQils/r5vmQ/kAU5UJR26mb+XFB1XHt0Oof/5n+oLLo0RUg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (internet-251.radiolinkplus.cz [109.205.241.251]) (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 4dCnTp4cMzz9K1; Fri, 21 Nov 2025 20:52:30 +0000 (UTC) (envelope-from mmel@freebsd.org) Message-ID: <5f042521-03d7-41c0-95a2-5711595d0f62@freebsd.org> Date: Fri, 21 Nov 2025 21:52:29 +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 From: Michal Meloun Reply-To: mmel@FreeBSD.org Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) To: Konstantin Belousov Cc: FreeBSD Current References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 21.11.2025 21:02, Konstantin Belousov wrote: > On Fri, Nov 21, 2025 at 09:54:23PM +0200, Konstantin Belousov wrote: >> On Fri, Nov 21, 2025 at 08:08:47PM +0100, Michal Meloun wrote: >>> First, many thanks for your efforts, but this check doesn't trigger when the >>> problem occurs >>> >> Hm, ok. This is a data point, in fact. >> >>> >>> To be more precise, testing case >>> on fresh kernel(d8bfcacd12aba73188c44a157c707908e275825d) >>> with PMAP_DEBUG defined in pmap-v6.c and with >>> trivial zero check for first page at this place -> >>> https://cgit.freebsd.org/src/tree/contrib/jemalloc/src/pages.c#n281 >>> >>> causes this failure: >>> >>> __je_pages_map: addr: 0x0, ret: 0x3087b000, size: 4096, alignment: 4096, >>> prot: 0x00000003, flags: 0x0C001002 >>> __je_pages_map: i: 0, p[i]: 0xFFFFFFFF, p: 0x3087b000 >>> __je_pages_map: i: 23, p[i]: 0x308E5F94, p: 0x3087b000 >> >> Could you, please, when the failure is detected, spawn 'procstat -v ' >> and dump the memory map of the process? To be clear, I want to see all >> of this: >> - the address of the mapping returned by mmap >> - its size >> - the location of the first non-zero byte >> - memory map > > Also, regardless of the output above, please try this as a wild guess: > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..5c6ed51706bf 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -2222,7 +2222,7 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > * Remove any pages that may still be in the object from a previous > * deallocation. > */ > - if (next_pindex < prev_object->size) { > + if (true || next_pindex < prev_object->size) { > vm_object_page_remove(prev_object, next_pindex, next_pindex + > next_size, 0); > #if 0 Unfortunately, this does not help either. Give me a moment to collect the required procstat. From nobody Sat Nov 22 00:39:25 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 4dCtXB1ww7z6J2Tj for ; Sat, 22 Nov 2025 00:39:54 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dCtXB1Dtzz4NcS for ; Sat, 22 Nov 2025 00:39:54 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763771994; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=apbDxEPccaWusHwTXv2sX6R0/iQ8I8StrvL8un/qI0U=; b=IUh5Mo1zT4+uM4lBz9UYtoJNvjoYPHVF5EK2ZTPsOXoSNbFNsShhrHFA97MCPrXmOMRFMB 0cjo3yot/elShXZMmGW1IFW5Jk0HF++pgVGEFFdmAV3pbML1AGV5P9R1i5qzvEzNozTY6F t2cbSGrYJ9bTpkqybCvv+EQRJ77Ta6P0D9fr+OlCRXAxu6il9+9YQb11UZuBzi83fIC0Y6 YpsT7/xTm9T0aQei9jCJGHv8uouhJUG2N0kR/E28bnrqZEzJART0ZH45wZThE5aeZXQNGJ V7pVKmNgtPXjZARvXckC/kV0c5M7L/TIp471csOieC/7SY8aPyfLyKEQ29G06A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763771994; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=apbDxEPccaWusHwTXv2sX6R0/iQ8I8StrvL8un/qI0U=; b=SUaqoBE/01VHiFK/nhkmFZ3r9WDPnp+Hmul7Dkh26M74W3KLX+2HOY0/n4lg6HKb7+jyqY bKXrQ/VDSqYtYd2TMs3aCT1sCSUIsSGNTTpusp7uZ6OGSN4x81las+NzyJO5uc9e1BvLPD ClxQDzP2LcIrtFUDCae07V0Wbbsc7eFDuDqXWoElnTlsaq6mrk0GNlCVlUcUAgnQVDGmSl wzlKer+Su/LQyf9vyMmvQ8y7xnLkg5VxFMQYlQO7ZYSHoSCPOJJ8XWXfhK+d7oWpcR74r+ osn8LixQAY1PHCjQ1mWN9OcAyN7yKr08OvtPewwmYUj3W/G8xhrztzzH5i+Yaw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763771994; a=rsa-sha256; cv=none; b=dMJ4zGAE6sxyzFnd8TIYWZVIXi/loboVDffjggorYIZsr7bAHXxGBArtfORQbe1JKI8rIi 6ESjWzWgjdGlP+QRh+jyAU8wtiwUNksdxnNocCQbhrVHwnhCQK0/5/P4fcv7aO4PrybKKR 4F50ir+7xukg/G/4fbfIKL8syeYviW8k1NGCNnFzkU3LNNV1gUtOmuntIlemZ/hyI/+1Ng Q39C9ZxSqXKV5xTnKOXThk0EbZnE/R0vrLUsZwybmT6lltHgfi8WP3QKyldoJJTCOvgn+F 9MzNfyjMQ1Vr/SOxe/v7rLPojN5L0VHu2c7bfZ0lW6RZOfV5itZt5xucjTvx4w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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 did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dCtX968M5zFMD for ; Sat, 22 Nov 2025 00:39:53 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sat, 22 Nov 2025 00:39:25 +0000 From: Lexi Winter To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iPxAItqO82/b+ZSK" Content-Disposition: inline In-Reply-To: --iPxAItqO82/b+ZSK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable void wrote in : > A newly installed system was installed with pkgbase > It was then upgraded via source with git. > This is very recent 16:current amd64. >=20 > When it came to installkernel, it was suggested to > set env DESTDIR=3D/ which was done and then > installkernel proceeded normally. > The same thing with installworld. the point of this warning was to prevent people from running "make installworld" on a pkgbase system. apparently, the warning was not sufficient... if you want to update using "make installworld", you should not install using pkgbase. instead, install using distribution sets. --iPxAItqO82/b+ZSK Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaSEGOgAKCRD1nT63mIK/ YNC1AQCCgb04cHN6kuhB42JJH/FrKaXIVflVCWsqyFt2wzVVJAEAnFIB8jLb686W 6hP6uC2yVKoAaCrjED7qyTEUhkHoMQQ= =VBxX -----END PGP SIGNATURE----- --iPxAItqO82/b+ZSK-- From nobody Sat Nov 22 01:29:27 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 4dCvdp4Dpbz6J5VR for ; Sat, 22 Nov 2025 01:29:50 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a7-smtp.messagingengine.com (fhigh-a7-smtp.messagingengine.com [103.168.172.158]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCvdn2csXz3HZG for ; Sat, 22 Nov 2025 01:29:49 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=q+aSMntM; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=S+WkVyxu; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.158 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id C9A411400150 for ; Fri, 21 Nov 2025 20:29:47 -0500 (EST) Received: from phl-imap-13 ([10.202.2.103]) by phl-compute-06.internal (MEProxy); Fri, 21 Nov 2025 20:29:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1763774987; x=1763861387; bh=cCeyOkXnJDyq0VbQocVDqnZLCzl8xfiRUElRcWIwL4Q=; b= q+aSMntM3zzvI0KJg4Y4zEoZxplIUn5lP7BJ38wXbsoHELw+MmG/L+7zjU/Vm6e5 UrIr2fpXZLjg5ml8knCu4GcmAdyZc4ywqaLYPWXU8ZoB3N946Hi14eTIqrb0i6JV 1fpYCyThGmuDau1C12tYpklHmuuDA8WFC6/OYwlsP8iVXcFmafDI+p5pMbpdTHJx 45lSUjsqlvNtm2fDCn9UIe1stgWtRcW7nezduDe4qmUt7GK3I4pI3MXnMkqD4OgG cdFUdjqUEEl0fradcgkldynB2lYjNgSyAdLB43QSAHO+WS/LhwJDb41Z3WXXQ98/ xKkv16JY3EwOxR34jMBRLA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1763774987; x=1763861387; bh=c CeyOkXnJDyq0VbQocVDqnZLCzl8xfiRUElRcWIwL4Q=; b=S+WkVyxumbCFnR3gX OTpTJjYAMR2aRn3WZjGG2dKjOsPGdda1lHQnAGF0SS5pvFzNlrlmvNv1+kP7+9eA l73VmvyT0P+CB04k3U9nQneFsqtudxSlPWTKdTQ07CrBxg/IYXYyVlaawby0IkT7 VyZr+LCGiE8M6bl7VzedPIREXkV7H8JdHSt58LRqnzTwoPxxXounjCo7X5EPdc3P /bnvhMwzyTibcZowiujEBXezOabPgZ2AJ320Gfig8zhsx7U+XwuQoPvqY6a9UsnP 8XJgLASTR9f1aSzJrZb28AvTvYHpPIpbBx51y00b7OJjWnxOvFJZdUmKmIiaNLiO Aun9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfeduhedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvkfgjfhfutgfgsehtjeertd ertddtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeeitdefieefteeiffeffefgjeeuveffledtheffgedtfffhfeeugffguefhke fgvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv ohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuth dprhgtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 8A6FF33E0072; Fri, 21 Nov 2025 20:29:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface 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 X-ThreadId: AOqOAcbMyp1J Date: Sat, 22 Nov 2025 01:29:27 +0000 From: void To: freebsd-current Message-Id: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> In-Reply-To: References: Subject: Re: changing from pkgbase to regularbase Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.08 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.158:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4dCvdn2csXz3HZG On Sat, 22 Nov 2025, at 00:39, Lexi Winter wrote: > the point of this warning was to prevent people from running "make > installworld" on a pkgbase system. apparently, the warning was not > sufficient... Sorry, I'm not with you. Sufficient for what? I mean it was a sufficient warning, I just had to heed it then do further things to properly depkgbasify. > if you want to update using "make installworld", you should not install > using pkgbase. instead, install using distribution sets. I wanted to stop using pkgbase completely, without having to go to the trouble of a complete reinstall from installation media - a state of affairs I'd consider to be a regression. I'm happy to have found a method of de-pkgbasifying without complete reinstallation. From nobody Sat Nov 22 01:35:41 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 4dCvn54ymcz6J5g6 for ; Sat, 22 Nov 2025 01:36:09 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dCvn530yPz3Jt7; Sat, 22 Nov 2025 01:36:09 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763775369; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c3XLWYTcTLaqSKHMBIv8Fqm0P9iiqNC84+QBDgrQmgA=; b=xPT19lGkj+qyWN8JvvANHpwU7xomdO8tpBYKB3TUueqJzROUHNQumRQ88ph30ouqMMC02e r8WQPA/dSdN71XyVQMr2Bcj/V9+hqJf/hUJFHvV0teqOmi0AE2mLMIODwtX989HcWp42Pe 9NGf0nsR24UQSJiS5J+KabmLZJoqVfgf+HU/OZb9gKYe9DB4PuFFX9XP/KeqogxF5N3BXJ Fhuqt71zlYIrmJrjYdSOva68DsiIa+6S14kC7Th3ttJ2Y5AxXtjb0sFRFEBa+wgcipure3 ErfkuzhQR2Guprf6Dy3CERDOOO/of1sUClqQL7ctEWyVtqhAK7ky8hibcrW6eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763775369; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c3XLWYTcTLaqSKHMBIv8Fqm0P9iiqNC84+QBDgrQmgA=; b=l9xmfdB1kL6fsH0gahWlXSecs8fOEDrdGrM5aW7IB6v2rQkSshOG3ZuhFKsxnH1nVMa7sD RhAL2Vi3WK5cxWphjV6eHZBxH4AwBbnvpsgd3WPm74ZAFT2ltPnlB5P47RczOzSqD9KzFc 8G6NYN/4U+4Nt4DmvEsIRxJnITiTLa2sVnF8ytlA8ONaFY62V0E8cv6QX0jlQvP4TVxZ/B RFAedsplmstrQpkWCcN3JrGqtQW61FEPxXh9V6wdlMcNftC89PrbNbzDLLLfGWqT40PMo+ qM8IvakjF6AyidSOEB5zCUQnupByzlGqDccMtOw7dPZJe4TCLVZL2AXCs4QU3A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763775369; a=rsa-sha256; cv=none; b=tgQ/hIeOH8zgzwH/SNEFw75QVXEDqFeucji+/irYaNepVesyzXVskKzQYaBvypOTcsWFP2 Tr540OGSisn3InbhsyDu8JbxJQElKOT7kPqpQWFm6ZbGyTyURZ9/9u8o2AkHnF7lsvu7vO hS8z81nr0rroJwc91SxZEerL7k3gFvjQlIxfddrQZ/e5r13y8bTA4ZxNKBb3P/Xb1ykZ0F 3x1Sn3LBPOU1pHM2Ay6lcnDaBa6EVKinPFsfX7Lk2ki1XNXhc217rioFbnJr0cAPPUDI6S IMOeGSuk/FDKD84Dhg50OeZa5VGcUB6Fdh3jjZ01NyZIo3i2rE9jk5ibq3rNcg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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 did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dCvn50CN0zGhZ; Sat, 22 Nov 2025 01:36:08 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sat, 22 Nov 2025 01:35:41 +0000 From: Lexi Winter To: void Cc: freebsd-current Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: void , freebsd-current References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dGM/zym7VA4ZgRRe" Content-Disposition: inline In-Reply-To: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> --dGM/zym7VA4ZgRRe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable void wrote in <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com>: > On Sat, 22 Nov 2025, at 00:39, Lexi Winter wrote: > > the point of this warning was to prevent people from running "make > > installworld" on a pkgbase system. apparently, the warning was not > > sufficient... >=20 > Sorry, I'm not with you. Sufficient for what? I mean it was > a sufficient warning, I just had to heed it then do further=20 > things to properly depkgbasify. =20 what the warning says is: ERROR: This target should not be used on a system installed from packages. nonetheless, you ran make installworld on a system installed from packages. so, clearly the warning was not sufficient to prevent you =66rom doing that. we are discussing ways to improve this internally, probably by making the warning more difficult to override... > > if you want to update using "make installworld", you should not install > > using pkgbase. instead, install using distribution sets. >=20 > I wanted to stop using pkgbase completely, without having to go to the=20 > trouble of a complete reinstall from installation media - a state of=20 > affairs I'd consider to be a regression. I'm happy to have found > a method of de-pkgbasifying without complete reinstallation. there is no supported method to "depkgbasify" a system. the correct method to not use pkgbase is to not select pkgbase when installing the system. an unofficial and unsupported, but functional, workaround is to install the system with pkgbase, then immediately run "rm -rf /var/db/pkg" before installing any ports, which will leave you with a system mostly identical to a distribution set install. you will need to manually bootstrap etcupdate after doing this, since pkgbase doesn't install the etcupdate data. --dGM/zym7VA4ZgRRe Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaSETaQAKCRD1nT63mIK/ YOOKAQCBX5WJOcPGcEE403GPAHGYPFv949m9dHXA9Yp/a7+ukwEA+ygRsKGQDKxe JN6MSbYB8Otv6T/cRbC5hNnjQjAZVwY= =KjeR -----END PGP SIGNATURE----- --dGM/zym7VA4ZgRRe-- From nobody Sat Nov 22 02:35:48 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 4dCx6M3Nntz6J9kj for ; Sat, 22 Nov 2025 02:36:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4dCx6L6Vvcz3Ptw for ; Sat, 22 Nov 2025 02:36:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NAXMafan; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763778963; bh=EofD3P1DyMI4OH7WznfQGjFARzq+Mka8MBR/9NEI3mQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=NAXMafanL3xcZ2LIK8Rgiz0wVvCQlzoc8FBNmxmNyccQCaSKRDYpaMd9+NQ1dyoPAFmxGPrkjJS6CUhJKOKwJMUKpvo1b7zeetBNg82qhiPg9sLjx2S/weR0OeeprMqMNBkQeJ+JR9MQ2jNNnh9ZGFeNlT35YthEZrwb7mHr3UY0cuuc0FdUICL6P8mr7Fi/rufj5gQDvrh4sxwhfvWr8nml/r0ZVnVPTVlswbqLcHZdi/RdSKq/c9xnk+7P340OR248fgR/WRzpKtv3nN6t75AdKxzHCyLJByFZ1kUfqvBl2EbwFR7q2p0tClVQl3PoM0TZo1Qk4iN5CSz2UmwJjQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763778963; bh=m0xR8acDYlT+7y6qC7EmfpbrD2GmakXkXHN9rd1jal8=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=E0DP0j/oDT9eZByySDcAmesUebWHIxj/2xLyA1b5kGp3doAwvryfs5+7x0HvEp2l6h+xl6jxNlxu6Qn6yutiL6vGjiSkmpSEOOzCuIqTSpDfTTeTOU0KQQbNeB0cr1dbe1kIv0nQ2RzWP7luPBLOt+6fUqnocpdJf9LDNsTIUo2iknvCVCXOVYnzYf8FEAmi+2v3LIogYbi5h+GyQky0Z8z+BoQug+zwFp2Kt9HPYFV884bRvMV0ape3bZ2OC/l1yauxclRygL6EXX4Lt07/YvBv2SxrqlS5rCzXgguEsuDcA7pP0fhFHGHCIlK1MvZHL4dcm6bcFttYsqorpIBCQw== X-YMail-OSG: 0S4sGPIVM1liYuAaFLN8vf15HxHBGJoMUK654mbkUmfa6sr3JR4Bz0UzNeUuSjT MAm0EsidYD8ZFpNcEYNHYXCqzskZLDl_mO5ytJUoQLuUqzXH_XUFKDEvd4GUnykAZP3G83NkMHb9 A7Bkej24nzwGY3kGX2ifYwfosZtU9Unfc.mKBaD2NclmjwUgtXYYVVdxrliNN4peG3bsvexesnm1 rCZtJgTcvI2J3ra9AQU4lSzFNou45mfpL9DKllZSd0pG8KWX6jpauEZh3jaAuM40jrtgTpyHNpGO TARXNaDEZQaOzc5fIooSRioUklbCT7rhFm2gS1hhyXswqXIjblua4tNSEkl6d60ZgnbrthA3tpcn 6Vz5mZya6aW3Iror.j9kayhE9LUJbehFaPxzVx_Y4XlCvWyitlW7ujR8w3LOo4_rrOhqJJXj_Q7y NceIZpBF4Rfb0l2YZP_X5u1U2YMP.AkouyKvy5AgMtDpTM2pwcUCrlnyG04WLwebHufHSgTfgRqY iyrHQ1GztTdEB2LyDx8.juhIQVq5bInXYyajIGITHsdWZNLHe8ou.dMMYEHfq9zW23_zh77XkxmT MQOeMqpbUkxh627rw29N5S5urEw6XDIWIvehzQzQStP.jnaY2oBfhIebHSajRxn5x2RWAulLtr9T h7yxkefs43rsaoCEqUVuT1TCOr4jt_vlTIKQrc2ffPLLbVSLFed0rjcJnZKBYPiIFoC1VDpnmYUE NVox4.nNWDuqGIiZcXDAQNrFSxS2_.S3KRxDD9HdoZWe3S1UhhpgsS4XuU7RZQJPGFIw0RxvH0Dq R4r_f9yBKm6fNgubrXVZddpSXm7P8ucJpUsVINIVe5JVmI633al.yHzdV0fZctpbXdckS5AzWyDJ qd3uzwjKbqXO.xKRsKWwBOyZ9NPUIBXiWULZfssej2cJbiqB6nQCxni2s14YXxpDHvtfoLqBtdbd kbPK0uixbc3E8O3OhCZZtMcCAaiTQdGaHag_jFNimhZpbN0sUpnDqZMICJ1glDTLnZWgZ0mvqeuw 4mr_zaPZ5r0pWmsRPklOCgSTFhi0HsNc_Xu0eiuBs.LlynUKaC7WfTYJB83s66HVvxwQ180CVPUy J3JyQs5LbdRuAJeeXBOFChHSGECJofcv.QBdFfEU3XAtUecpArJ0XiqEH6ddSg6lglKrUZ0Tv5UN fwsz7Fq74fm5dgShoWc50f1CyBEpWWcw9PFzlogu7_QSFAe3r99AQmh1MDhcRBbLgNlFIkItIpQZ 0joX3IlCzr_azK9f.uMHCdI2amaPnDcb56ufETDF3AIrOGjDjh_46WYMLPCzlYb6m3AczpyZiFnW _nsA2f6yvfFVFprFJTONAJ3GVoV9dQqDJ3pt4MpjZxJ_.xSyg9_.D7sFYiU3sUUXGS56FTXN8keX OVsF2.6ySRQ3NKfFW04z8OjgUJXl7pK2yQK3MYu23GvHCvL8qftux2ssFOKD0iWWkdE0LtFphbKv rG2YZU5oyRxAXznnjYJSU6g1PEEbysWv_d8Tmyj9FlWDMh1XKOTkmzMqfIC6Tgg8zPUEpcuol806 ZnWm1LOtKcqPngx_LwVrzLBiKd1RVT1KMrYohOnVIbqPGIGa..9qzWexhf9SxQJRmZgIrKM.p_sm 21wUPy1nYynOHxq1xUqg1I2ZJBUKGKuoy0LjuODTBv5vsZgsJtaazQKikNvL9oc2VmIGoUeR7TJQ 6rw28JvweQuiAFK00LFCw8jYwmdRpCSdAem9xassMXGMIxhGm_g0La.DZPXfPbWPKLklI4e_oFpW QGlW6dUg1CWuKEvLHf5xJkDiUKFrCMSac68WMgh1slN6hsyBw6i8qj6BgjOml5L.hLXzlbx3E3CN pqsN1fFFwGVTyYaSyEuk9ILFJJbhQB3.Hwq0fJwbfznB.vNomRJpu7xluXDXwWuaq7PP2Tvs5u9l 0K.wKc1WVw3G1pat9YsXtAZYT3oTnLU4fJKRYUsw61f0iIpJyPvlEGgGqQGU4fUwKfHAV4XJq.nq 93x3Gu3KMz_ZT6_GiV2yS_x8fIk4U27l2OwzQhmXN0M9DYcY0j.5GIkoNmfGsmfSuE0VRTB_tyUz du41sd3PhUCodWobRoZXEx6neC0L_HbQpZkagjKVFfTgEzsntpMJ6WpSKnoGLDuosyzm22lRdKEp tF6nz43.kmC_z4ZnVomTv7sb2Hj9VQo8BrvambGCZkxgRpWxAltjZGlGh6uE4JRKS5410fD2D.DT Fo7A6mLZ4rlRlNEgyZ0njNhlYQHTtJx4Ja8w7AkApvqzwFIHEJSwGU.8z4eZlxxcMNKf6tYESUud mQiMaYg-- X-Sonic-MF: X-Sonic-ID: 7e6fd702-0ec1-4e1c-b939-e3dd992bf6d3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Nov 2025 02:36:03 +0000 Received: by hermes--production-gq1-fdb64d996-22fw7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ca39f1ada6de4b8df072133a461e0eb; Sat, 22 Nov 2025 02:35:59 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: changing from pkgbase to regularbase [ evidence gathering for problems when using a pkgbase system ] Message-Id: <6C4D4B62-9B81-4106-9581-54AD6A441CF6@yahoo.com> Date: Fri, 21 Nov 2025 18:35:48 -0800 To: Lexi Winter , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <6C4D4B62-9B81-4106-9581-54AD6A441CF6.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.98)[-0.977]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from] X-Rspamd-Queue-Id: 4dCx6L6Vvcz3Ptw Lexi Winter wrote on Date: Sat, 22 Nov 2025 01:35:41 UTC : > void wrote in <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com>: > > On Sat, 22 Nov 2025, at 00:39, Lexi Winter wrote: > > > the point of this warning was to prevent people from running "make > > > installworld" on a pkgbase system. apparently, the warning was not > > > sufficient... > > > > Sorry, I'm not with you. Sufficient for what? I mean it was > > a sufficient warning, I just had to heed it then do further > > things to properly depkgbasify. > > what the warning says is: > > ERROR: This target should not be used on a system installed from > packages. > > nonetheless, you ran make installworld on a system installed from > packages. so, clearly the warning was not sufficient to prevent you > from doing that. > > we are discussing ways to improve this internally, probably by making > the warning more difficult to override... An FYI: I've been doing some of the testing for the jemalloc 5.3.0/kernel error notification issues seen on armv7 and i386 on main 16. (stable/15 and releng/15.0 do not have the asserts enabled to report internal checks.) My context is main 16 for this. But I've been using an official-distribution pkgbase'd environment from long before this activity started. I created an alternate kernel, installed under a distinct name for some of the testing. I did so from a variant of the /usr/src/sys/ for the pkgbase system --not replacing the official kernel(s). I did use installkernel for this, with INSTKERNNAME= in use with DESTDIR=/ . I also touched the c++ compiler (c++ and clang) to allow it to generate core dumps for SIGABRT as the asserts are not failing for libprivateclang.so.19 or libprivatellvm.so.19 problems but libc's jemalloc and/or kernel problems. But I did not use installworld at all. Just selective copies from the built materials. I did use buildworld. I have *.orig files for what I've updated --in order to be able to put back the normal files. Gathering evidence from a pkgbase system for problems that occur is a bit odd for sure. Side Note: The actual activity that is know to be able to produce the failed internal checks is: llvm/clang build activity during buildworld . In some contexts with memory pressure involved, it has been seen on pure armv7, armv7 chroot on aarch64, and i386 chroot on amd64. (No one has reported having a pure i386 test environment.) The error report is indicating that page(s) that were allocated that should have been zero are, at least in part, not zero. My core dumps for an armv7 chroot on aarch64 show the jemalloc 0x5a fill pattern in the non-zero areas. That pattern is for deallocated memory. Michal Meloun's information indicates other, more general types of values are possible. === Mark Millard marklmi at yahoo.com From nobody Sat Nov 22 09:09:31 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 4dD5rM1dllz6GhjH for ; Sat, 22 Nov 2025 09:09:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dD5rL5w93z43qH; Sat, 22 Nov 2025 09:09:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5AM99V3o098058; Sat, 22 Nov 2025 18:09:31 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1763802572; bh=oaOaTFgg65Q86SD0z9MVGUkSP74ZAiQDrLXOESyl61s=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ECFmAgyDTsXACd/q/7p6/hqoPF8KxC3ZilxdLAC75A60kXRIvwAwcn3DCWNV61WL0 dzM4h1/Ho4iKCUGEib/V6aM877Jf+9fK4pJBUuzMvKAzAVRd85srFbpKIjviDbLsqx w79BsRNiZMd0LlkvtzKRjmOwXcfWZCGI2dpwInxE= Date: Sat, 22 Nov 2025 18:09:31 +0900 From: Tomoaki AOKI To: Lexi Winter Cc: void , freebsd-current Subject: Re: changing from pkgbase to regularbase Message-Id: <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> In-Reply-To: References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dD5rL5w93z43qH On Sat, 22 Nov 2025 01:35:41 +0000 Lexi Winter wrote: > void wrote in <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com>: > > On Sat, 22 Nov 2025, at 00:39, Lexi Winter wrote: > > > the point of this warning was to prevent people from running "make > > > installworld" on a pkgbase system. apparently, the warning was not > > > sufficient... > > > > Sorry, I'm not with you. Sufficient for what? I mean it was > > a sufficient warning, I just had to heed it then do further > > things to properly depkgbasify. > > what the warning says is: > > ERROR: This target should not be used on a system installed from > packages. > > nonetheless, you ran make installworld on a system installed from > packages. so, clearly the warning was not sufficient to prevent you > from doing that. > > we are discussing ways to improve this internally, probably by making > the warning more difficult to override... > > > > if you want to update using "make installworld", you should not install > > > using pkgbase. instead, install using distribution sets. > > > > I wanted to stop using pkgbase completely, without having to go to the > > trouble of a complete reinstall from installation media - a state of > > affairs I'd consider to be a regression. I'm happy to have found > > a method of de-pkgbasifying without complete reinstallation. > > there is no supported method to "depkgbasify" a system. > > the correct method to not use pkgbase is to not select pkgbase when > installing the system. > > an unofficial and unsupported, but functional, workaround is to install > the system with pkgbase, then immediately run "rm -rf /var/db/pkg" > before installing any ports, which will leave you with a system mostly > identical to a distribution set install. you will need to manually > bootstrap etcupdate after doing this, since pkgbase doesn't install the > etcupdate data. I don't think disallowing de-pkgbasifying is a good idea. IIRC/IIUC, legacy distribution sets goes away on 16.0, at least from dvd1 image. If other images that don't have pkg from ports in it still keep on providing legacy distribution sets, warning on top of RELNOTES would be sufficient, but if not, installer should have de-pkgbasify option menu like "Do you want to de-pkgbasify for source upgrades?" before installing any non-base pkg is installed on installer. Here is freebsd-current ML. So most of people would be on the way of source upgrades. Imagine upgrading to far future FreeBSD 666-Release! If 15.x is the last release that provides legacy distribution sets, how many step-by-step upgrades are needed who are new to FreeBSD at the future to be able to switch to source upgrades to become FreeBSD developers? *Maybe in such a far future, looking for installer image for 15.x would be quite hard. Anyway, we have some additional years to deside and fix before 16.0. Regards. -- Tomoaki AOKI From nobody Sat Nov 22 10:57:59 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 4dD8FS6c5fz6GtH2 for ; Sat, 22 Nov 2025 10:58:04 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dD8FR42mhz3JvJ for ; Sat, 22 Nov 2025 10:58:03 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=aU7xF4EG; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=MlIVceHj; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.156 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id 393CF140021D for ; Sat, 22 Nov 2025 05:58:02 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Sat, 22 Nov 2025 05:58:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1763809082; x=1763895482; bh=JLpek9i7DM +YMxb6M8QbSBFK94nTC4zvYhe21T4g3YQ=; b=aU7xF4EG6UKj4ojjr023H10KB1 iEf077YfeM+Q2HARfPIZD/4pXLUnRZnoTccoYKyFVyj8mWFvmPxe8HfmU+Jq6jbh xcZGnagGmjFq9awOoaAjYeSBzY+/vh6XrHEvrSAAkNW34mWofz3bnrc9wLxq8cXT mgluAq1pyhrG1tQectkLugquNP7p668YRNCidvzabfAjduOZfQTgascWw/4kbDv4 HpFLPYkkPbE8Tmb6OiK6UBGbB/8uTxkVimP4Yj/f1EPk1iFDHoHzfEWi5IyAECDk xHrcdxVvALR/thTJL/YLszrzSkTbGRIpu34tI+EimeyUtZxMj+yG4/zCntmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763809082; x=1763895482; bh=JLpek9i7DM+YMxb6M8QbSBFK94nTC4zvYhe 21T4g3YQ=; b=MlIVceHjRm80sXbSa8Ss2k/tsthwQvtAPRwWA2s5zV6IS0y+DFu n6jLOmgEeBcwCZhMqqlz62rhsaP3BpTp8tvZxbxAKk8PodYDpwE0jRmid5oomB2D EWKItmdu4TxgWW46XuuMmxyvxqQo1vhAoSoFLtXs6tTfNGcxjIIVDyywZ5BkwmHs /CTp3yAJKFBycm0vo2sH/x1pAmEf+vNtZakTKsDaufbCfDEkBDE6qAR3EnSbihUa OXLA0kuuZK5Il7+JgKQu9+rannT3Io1rnLhJsIxsrBE71QxVYjzexQcV2kLlMrza 1JYlmFaPOU1I1c96rdf9T1lXJlf2OglSULg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfedvieeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgf eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 22 Nov 2025 05:58:01 -0500 (EST) Date: Sat, 22 Nov 2025 10:57:59 +0000 From: void To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.156:from]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4dD8FR42mhz3JvJ On Sat, Nov 22, 2025 at 01:35:41AM +0000, Lexi Winter wrote: >probably by making the warning more difficult to override... A retrograde step IMO. The warning was sufficient to prevent installkernel-by-accident. Which I think was the goal. Accidental foot-shooting. There is no need IMO for further guardrails when the goal in this case was to move back to a traditional system. >there is no supported method to "depkgbasify" a system. IMO there should be. >the correct method to not use pkgbase is to not select pkgbase when >installing the system. People change their minds. From an immediate "oops" to a repurposing of the installation further along the road. Just about everything within FreeBSD can be changed post-installation. Why this issue with pkgbase? >an unofficial and unsupported, but functional, workaround is to install >the system with pkgbase, then immediately run "rm -rf /var/db/pkg" >before installing any ports, which will leave you with a system mostly >identical to a distribution set install. you will need to manually >bootstrap etcupdate after doing this, since pkgbase doesn't install the >etcupdate data. That's good to know. It'd be useful to have this in the handbook somewhere. -- From nobody Sat Nov 22 11:39:56 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 4dD9BL0CDWz6Gxc8 for ; Sat, 22 Nov 2025 11:40:26 +0000 (UTC) (envelope-from ivy@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 4dD9BK6d8jz3V4T for ; Sat, 22 Nov 2025 11:40:25 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763811626; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jNYBb5M3H+RgJzz7Ca0HnupyDTHsGpyAMWDSsQnZvRk=; b=fYjvs/m8FBzkH7+kEe/neAa2Kr/xKbg23FAuH0Gih3RBcDSNQmbIMB0O53Vl27TaNMGLqQ dUEnq7pyyx0HeVD9zaazhrdGsviYcwj+uApLeizp5WK7lU1P3cBli0w20KGri1/3ItDrPR PCqbk0Gz0SvwVkAZucmlIxuocCsufD4gKgP5bjP/q7npk+cRIgc3EfN5aIvtr45YPy/Gm/ V5ZE4LoH6Gi3QSWbVzcwCYxDCE+2j1p0/TiqE7w84cqATUmZV3UNOHyGA0N4TleGy4wciN 2vjNxQzG8GkTlvcDoFKQekv0Y9P6wvAO5bK81Nbq0BT1DsIM+IwQD8jebggcDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763811625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jNYBb5M3H+RgJzz7Ca0HnupyDTHsGpyAMWDSsQnZvRk=; b=O5u0RktA5mkAi0efK8JTn2Lj7gAdfpKqEf8Kg3AxGsil9YRaWSGMrE8A1zwmiiZanJ2Bl+ KgksH0kdSRm2rhLhEZhysvtlTsCdUxJ/eTaAasYlirApEdZWl7RUWDUPRaYfI4g9gnbz/z 0SHu0JLbThMB7Mzo7dCzygmMt1AjUjA/gIIgtrTRfyZQCxr0dvyrIkwxa2QksCjr+cWiqo vqL6TqvAA7JGIXV8B5hPnVeqgKRi5e9rPWFTEvj1qRWa2lbZ8UdkRYabXK5+rUmP6SfOuv RIwXgc3j4qVkiWu/9PlDPMePs7wVwDGaKXqtWcPaSlrKq2QZP9h5GIXlkevRHw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763811626; a=rsa-sha256; cv=none; b=fFX8S0yYCE0ggv1j442sSc9tLnPedEo1fJzCK6BmauZe7r4ArF/fKe41IfDfXlViaBJpmH Ea6JnyLDcC8kYLsiM72fsze3dkp1WJepGz0T8vk1GofowA5/evCP0XzDoDHXC8wbl8OAi6 dcmOx0hye9EYLYXwZrvI3REs9PzMgYlIYvnuDAK5ou2GDqTQLTWG7Y9XiD/dKLVPJG/y5A Mwakc2reYqsMJQhrw3enHSE2huYAV2sWhlgn918pzvJ+ZCzUoLhT1Xi6p35W1nIlNTY1Bt RLHRxDU9QpHkEkGCVGlFAFvL6k1bBQW/3jhS+tm/E0IDioOIXr3mQtRJyutFYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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 did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dD9BK4R2GzlDg for ; Sat, 22 Nov 2025 11:40:25 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sat, 22 Nov 2025 11:39:56 +0000 From: Lexi Winter To: freebsd-current Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iuUNls89A5s7wFsb" Content-Disposition: inline In-Reply-To: <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> --iuUNls89A5s7wFsb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Tomoaki AOKI wrote in <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp>: > I don't think disallowing de-pkgbasifying is a good idea. we don't disallow depkgbasifying and there is no intention to do that. what this warning is trying to communicate is that running installworld on a pkgbase system DOES NOT depkgbasify the system. rather, it leaves you with a pkgbase system where the packages are inconsistent with the installed system. if you have correctly depkgbased the system, then you will not run into this warning to begin with, because it only appears on pkgbase systems. --iuUNls89A5s7wFsb Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaSGhCAAKCRD1nT63mIK/ YC+8AP0S8OVM1Yw7+87wOfaULqQ29uqSyAuiSj8OI1DBbXd6ZgEA0zTIMNIzZmhD 3Wv6WFW7PwvC/tzNidAsesm6R/hGHgQ= =a26w -----END PGP SIGNATURE----- --iuUNls89A5s7wFsb-- From nobody Sat Nov 22 12:28:05 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 4dDBFw0d9xz6H2Qs for ; Sat, 22 Nov 2025 12:28:36 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDBFt2rj5z3dx3 for ; Sat, 22 Nov 2025 12:28:34 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=sdDjeL0W; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=zrDturSv; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.146 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 899C2EC0090 for ; Sat, 22 Nov 2025 07:28:32 -0500 (EST) Received: from phl-imap-13 ([10.202.2.103]) by phl-compute-06.internal (MEProxy); Sat, 22 Nov 2025 07:28:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1763814512; x=1763900912; bh=ZeRXsxBVQzf3a5l4kh8pstJqqGctPJ2KKSKM1T/mFPg=; b= sdDjeL0WFZsDsJoMuMMfm5n9HmGIQASv4JHnUmkhBoMpI9yrj0w2Lh668TOiUOVn 9NtukBCQOEjNo/m8FfqNQ2sd7Vj94tQxrw6hcEWTz60yqbhrybeVXw0PxijIkG4U eac8Ssgpt6leC8ZYM1lBlUQ+r8YgNdI4NGeDDsVGrkWRfozgOP0/yqb7Ox1A9k+I 2oSLorKjdNneJQe6ifaMUKLRGbVfDxOqqehuE3T8TQnI00LbYYBSyRz4l5BVTN3N UcInmW48OPwNSMdQrQ3lhwGIH5+B3maohd3cj8R5tBcL450HbxIkxzG3PH6QfyZc PLGU1xDWImOIDXuAcPP8Qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1763814512; x=1763900912; bh=Z eRXsxBVQzf3a5l4kh8pstJqqGctPJ2KKSKM1T/mFPg=; b=zrDturSvRDamFYFcY 5DM2N3Ez3bxLc0eyku1nF0WuGU2qqU4998KSbdyWlnVbTM62U/pxnfV3HeESEBk1 kAslhBNu3a/B32ZRP4cX2SzeQToOmsOhiN3l5kUCnrfQKF167/fyRXUw6uAntCqM BnQqMiJLutfvCLJN3P7eDicYqMc6qyC5rudMQbTDd+dCeVG7V5CdCn7xMXW9EXpi iSxvw52IPJ9KWuvLeqiFwoaqpGEuckA19m1BEhpaKMd++bvOAbWV3UNYQBJ3YzBV B8MOdnL2yaGQ8Ek6Hubhq3NZIhRFOmGr5oNP/WcS7pivq69szkmJwz+7kaQFLYhg LaAcQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfedvkeegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvkfgjfhfutgfgsehtjeertd ertddtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeeitdefieefteeiffeffefgjeeuveffledtheffgedtfffhfeeugffguefhke fgvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv ohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuth dprhgtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 3A5F433E0072; Sat, 22 Nov 2025 07:28:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface 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 X-ThreadId: AOqOAcbMyp1J Date: Sat, 22 Nov 2025 12:28:05 +0000 From: void To: freebsd-current Message-Id: <3cd5a594-8f0e-4ff8-a54f-440611c3a7bc@app.fastmail.com> In-Reply-To: References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> Subject: Re: changing from pkgbase to regularbase Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.05 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.995]; NEURAL_HAM_SHORT(-0.96)[-0.961]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.146:from]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEMAIL_FROM(0.00)[f-m.fm]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4dDBFt2rj5z3dx3 On Sat, 22 Nov 2025, at 11:39, Lexi Winter wrote: > if you have correctly depkgbased the system, How does that work, given that you said this earlier: On Sat, 22 Nov 2025, at 01:35, Lexi Winter wrote: > there is no supported method to "depkgbasify" a system. > > the correct method to not use pkgbase is to not select pkgbase when > installing the system. -- From nobody Sat Nov 22 12:50:20 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 4dDBlK1R9Kz6H3xt for ; Sat, 22 Nov 2025 12:50:37 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT TLS ECC 1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDBlH4D9Xz3hV8 for ; Sat, 22 Nov 2025 12:50:35 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=lzpcn5wu; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 5AMCoKnF019030 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 22 Nov 2025 13:50:22 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1763815822; bh=HMMnBHeyVowQvYDWnb6HNPsSBlJCdHwzm34mVjyKLSg=; h=Date:Subject:To:References:From:In-Reply-To; b=lzpcn5wuc4fNeAhJtSTj3gHKgxznmlClbqlIiztA1XWaF0gQb4wp310ZX/LP+jbMX CBCbwq1T79yG8jr/uHjEhuvMjlzzW7tPJE9NLw4UY8nMPN2Z9J+lCkzlJ6Av7Uk3au rESg/arTSymRM57USQV4dEyKffK7RHA3aWnfdbOPJNskae6kgJgq0w42QAF156V8j6 YWo43HCnj7BgtQnejw78WEmQ7enE6CYnzmw5V+9jVufO5AHHA2Y6C3/86Fl++HFUdd KllZ+sLm/fWvhgWYxdRYCFx+QqeQ5584jNj2Zs6RJyeXpBReWWW1Hg4Ka4p642wSYN DhKTLr+6oTrgw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: Date: Sat, 22 Nov 2025 13:50:20 +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 Subject: Re: changing from pkgbase to regularbase To: freebsd-current@freebsd.org References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.78 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.98)[-0.984]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+] X-Rspamd-Queue-Id: 4dDBlH4D9Xz3hV8 W dniu 22.11.2025 o 10:09, Tomoaki AOKI pisze: > I don't think disallowing de-pkgbasifying is a good idea. > IIRC/IIUC, legacy distribution sets goes away on 16.0, at least from > dvd1 image. +1 Dear Subscribers of the FreeBSD-CURRENT list, since a longer while using central build server and make install{kernel,world} over NFS is  probably the most efficient ways to keep FreeBSD up to date. We have had this privilege since the very beginning. Introducing freebsd-update(8) was a good step forward and made system maintenance easier for newcomers and for people with limited time or resources. The transition to pkgbase is another positive development, and one that will certainly be appreciated by the community. Switching from RELEASE to STABLE has always been possible. Why should pkgbase be an exception in this regard? While delivering a limited or trimmed-down OS with pkgbase is certainly possible, the same is true when installing from source. In fact, upgrading the world and kernel over NFS is often even faster and less resource consuming than using pkgbase. It would be a great loss for the community if this old, seamless, and proven-to-work method were ever deprecated in favour of pkgbase. Cheers -- Marek Zarychta From nobody Sat Nov 22 12:50:20 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 4dDBlZ4tJmz6H48B for ; Sat, 22 Nov 2025 12:50:50 +0000 (UTC) (envelope-from ivy@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 4dDBlZ0vkBz3hcV for ; Sat, 22 Nov 2025 12:50:50 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763815850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LALEhCgHuYsX/huEne405EMQXc7xFvDfDivH3ppfmcc=; b=n/EcD6K8gI/Lfs+Vz7ARBsK0dly8wQKJSF6VZkY6OKZ8VDlXcMiwgNUGL+NjETLEXkdS1N Z4O8I7Dg/vGAM1D/rO4+zfz+xdcIovNq99IbkIZn80A0aViA5N7PuCQ3sRtqrV6iBE1hXr +GSilhfXOZQnYfEb9Plx1+43zLMyNQzjHuaE0uzRv5SAfSZ9Dg60o3loOehfoAGQdtgeSX WRyelw5lxFD9aH4zhtF260PdqWF/DAW6mwzC84t05H4IZ/zU7s6cpn0/743+knc/JkQdAY lsQk6ErJt0lk0poKMFeAQNSxAi23jWLBSLTLrR1a69wVSZFcnGbNAtZT7zdX1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763815850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LALEhCgHuYsX/huEne405EMQXc7xFvDfDivH3ppfmcc=; b=g78C96Oy0Vu0AKqdYEyRTJvBgwh3E7Z+llY2KO5HUajCdOluiHuoCas/BU2+YaQtRA78yi 8tLfxiObhAto93F1L65ZcGBI7LRC3xUws8vGPiyacmxosQ+EqSgmM5+EOTHpGDTXMW1vIe d21JfCN+xBxrvhE5vS6N798ZJuVH5KeqJ6SmmUOymA5lEsyjmhBkNMg9wjPXRWtEc1f83Z xv1N1XG4qYi4l7PJ76UAVqtRrZYJTpTO8xU+ydanuO2DXD2q39Bn24cTQD+6ZGO2RdLxcT ZHaS2CXguVD6/Zs7CxbL5bzMTw/LKNCxc1krhFnWEvk65ZEn4Fnq8tSby5Ruag== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763815850; a=rsa-sha256; cv=none; b=mWGtJr5gOirSsH59RVjDJgBMSxXA0CACg3GX5YBaa5Rq8dAdFqVNys25H513HYJv8KMBc9 zHamxR2lvPb4TMOI59HWzgFkVSoIsDd0hAYd1K8oROWKEbTzPtL3CCJBb3QTmaWbxLE/n5 m6+EsQpAHOuO18JHtbM+9/dAJxtD+SLBxgE2SW3MF46CFIzeqo9MpOHjEknSoLT/8+OSJp oADU6BONF3CG6QSO9xvOdyfdwmdDLHVifzyAzmqnpdTlvI0mIhSXEFmVdW4EUhUdTFF61I xwMPUJAAkPyjKqBbB9Fp2b5CGFr8RwB91nB7bE6wuTY9egupRTTuPwlZD+8wfg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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 did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dDBlY5Xgdzmd9 for ; Sat, 22 Nov 2025 12:50:49 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sat, 22 Nov 2025 12:50:20 +0000 From: Lexi Winter To: freebsd-current Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> <3cd5a594-8f0e-4ff8-a54f-440611c3a7bc@app.fastmail.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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9hVzjs4sz8Oo15Z5" Content-Disposition: inline In-Reply-To: <3cd5a594-8f0e-4ff8-a54f-440611c3a7bc@app.fastmail.com> --9hVzjs4sz8Oo15Z5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable void wrote in <3cd5a594-8f0e-4ff8-a54f-440611c3a7bc@app.fastmail.com>: > On Sat, 22 Nov 2025, at 11:39, Lexi Winter wrote: >=20 > > if you have correctly depkgbased the system, >=20 > How does that work, given that you said this earlier: >=20 > On Sat, 22 Nov 2025, at 01:35, Lexi Winter wrote: >=20 > > there is no supported method to "depkgbasify" a system. > > > > the correct method to not use pkgbase is to not select pkgbase when > > installing the system. - there is no supported (i.e., documented and recommended) method to depkgbasify the system - there are methods to depkgbasify the system, which are not documented or recommended, but nonetheless do work correctly.[0] - running "make installworld" (or installkernel) on a pkgbase system is not one of those methods, which is why it prints an error when you try to do this. it is always wrong to bypass this error, except in two specific cases: - you have a very broken system, and are trying to use a manual installworld as one step in the recovery process, which you would then follow with a full pkgbase reinstall. - you are using installkernel and you have either uninstalled the default kernel package, or you've set KODIR to ensure you don't overwrite a pkgbase kernel (or whatever the option for that is called; i don't remember off hand). i think the latter case is unusual, but might happen on development systems when it's easier to use installkernel than update-packages for quickly testing kernel changes. =20 [0] actually i think there's only one such method, which is to delete /var/db/pkg after installing. to provide a more general method of doing this, we will probably need some sort of "pkg unregister" functionality that i don't think exists right now. --9hVzjs4sz8Oo15Z5 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaSGxiAAKCRD1nT63mIK/ YNnKAQDV4Te5BIMPHthaUD+m1Y9RkRTSyJpFOsllYZGXypswZgD/csbV7Lg29Dig HYe539ptnU8kvQ8Nl/jMrZk6c8yZdA4= =PSko -----END PGP SIGNATURE----- --9hVzjs4sz8Oo15Z5-- From nobody Sat Nov 22 12:56:46 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 4dDBtY30mGz6H4ms for ; Sat, 22 Nov 2025 12:56:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDBtX5r9rz3lNR; Sat, 22 Nov 2025 12:56:52 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5AMCumTR027982; Sat, 22 Nov 2025 21:56:48 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1763816208; bh=jDmUCh4BHAGNfzCrTyb+VM87JFvkUF6CdJaEbRz3rXc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=YBG2+gG+3yyK6j2fz1y28ZhdFJjTkG7Q9T2TPn+oPsm+W/+Hm2NH5Wc2vIUflUeR8 OsRh1xGYkk6J5vkknKHkPqc93zVB37SJmJR0kkZtzJ+8G0pPpjZaEKHG/XblHTfZMF 1M7ibDadmT4ubMtuuiIDEd0PhTu3xl+dB3O7xf7Y= Date: Sat, 22 Nov 2025 21:56:46 +0900 From: Tomoaki AOKI To: Lexi Winter Cc: freebsd-current Subject: Re: changing from pkgbase to regularbase Message-Id: <20251122215646.7e4f34e1955bca5dbf3261a0@dec.sakura.ne.jp> In-Reply-To: References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDBtX5r9rz3lNR On Sat, 22 Nov 2025 11:39:56 +0000 Lexi Winter wrote: > Tomoaki AOKI wrote in <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp>: > > I don't think disallowing de-pkgbasifying is a good idea. > > we don't disallow depkgbasifying and there is no intention to do that. > > what this warning is trying to communicate is that running installworld > on a pkgbase system DOES NOT depkgbasify the system. rather, it leaves > you with a pkgbase system where the packages are inconsistent with the > installed system. > > if you have correctly depkgbased the system, then you will not run into > this warning to begin with, because it only appears on pkgbase systems. Currently, IIUC, there's no pkgbasify and de-pkgbasify program in-tree. Found github hosting pkgbasify, though. I've not bitten as I'm on source upgrade way both on latest stable (currently 15) and main. But for new comers who wants to be FreeBSD developer, skilled and experienced but not on FreeBSD. would be hard to find how to de-pkgbasify. These kind of persons would want installing from latest snapshot of FreeBSD on main branch. So preparing way to de-pkgbasify on nearly final step of the installer (just before "after-installation configurations" like adding user) would be helpful. At least, how to de-pkgbasify like discussed here should better well documented in README and/or near the top of Chapter 2.4 in the handbook as a Warning. The best way would be let pkg(8) to fixup broken pkgbase information when forcible installworld is done. But would be complexed work. Anyway, no hurries. Upcoming 15.0 is distributed with legacy distribution sets, too. Regards. -- Tomoaki AOKI From nobody Sat Nov 22 13:01:25 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 4dDC0K61Bjz6H5Pj for ; Sat, 22 Nov 2025 13:01:53 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dDC0K5LC3z3n2G for ; Sat, 22 Nov 2025 13:01:53 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763816513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Dy7jqnriWqum+TYEbyQRSra+Cu+tKKJCcaOIxPyOF80=; b=A7Ky5PnYMtVnhqXPHEXJ9lCv22q4H/89EhBZNvLeXBqxBQZ0wgkqBgVOtyNcZ13ZWSF4jE jjtsnxrKRJM6aUft3wsW8gohLEUOQukDr16LovE5SfSsbBrsgCLrxHK9bwrfc2lLEsqcdl RLCN7IYG862+me9c1nNzI1Ruicewp04J4/2DxLkohGRw1DvzEEMRmyUfqzGJC1X+AbJoyM unBEt1GTTGUzonFth4lhsVKkfLYDYaHVcOndTB/mMJtYEnk1ghLiVq/m/hhmQBQhi/9+VY S99GglrRqqBhNCjzPU2DoVginenVmLZsjcTGfRQJGioZNr59lFn6HXBn9JMg2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763816513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Dy7jqnriWqum+TYEbyQRSra+Cu+tKKJCcaOIxPyOF80=; b=T71Vohzawj03joBwTYQK6zMJyzTUKcrlBr333blEJi/DcmtOmS6qAVFUXH4zrhOgULm/Fa caFwwz9gM5z0DDcFBkiANAgzlp6Mqaf2r/Yuo9Ddzud+hySPbeMLb5/mFP1mJoSvboDIxw Ac1mMKGBepNpF4xPgtmIeSo2mAXRJ4oeEadRxbTjqHbhzVqFN0CRwk+JQN0Iou8Zs+hiic NeLLCxXAWAf+Jl9FNZqgIDnccOXYfJ4kS5ES33LBCa1/8MqUXCrqDb0uQjRLPEEWdTvGw8 mYAr2EftAIWED6m9WTOl+vWafEgb6iVHgb3EEUOWXauYhLxhBo+wZ5zvwaTqcw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763816513; a=rsa-sha256; cv=none; b=YHZWr0bef6SmzDTagOFmaYPYgmeVC4XIJ6HKz/cUayUSGgSy9Oqh840b/vCJBIITak2TdW qCti8lzcCu3+LtkwLrtyy+SDRN5HAGDUhG8p8EHxRqDTsX+GhUh55s7bzyU+35Dd/O1tuG ycyL0/dvBsUCodTaipNWuoQSgAhmwVslD4oEEHSbipOWkcfWvRevZ2MlxiIoBZy6SLnpFq U9jreoRB7Tlmi7MYvTi5QM/Yoou5tztBrSxR2SirmHIUyVp52nq87m5ceWOo8/bABLVJrk YelBTb2F2k8hFUc3zZ2u+1pXxFUms4o3uVY77kyN5bdQ5KcXU309UZ1WMBQZpw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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 did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dDC0K3HyVzn5h for ; Sat, 22 Nov 2025 13:01:53 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sat, 22 Nov 2025 13:01:25 +0000 From: Lexi Winter To: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ULMpEnE2qcJ3nD16" Content-Disposition: inline In-Reply-To: --ULMpEnE2qcJ3nD16 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marek Zarychta wrote in : > W dniu 22.11.2025 o=A010:09, Tomoaki AOKI pisze: > > I don't think disallowing de-pkgbasifying is a good idea. >=20 > +1 we are not disallowing depkgbasifying. > Switching from RELEASE to STABLE has always been possible. Why should > pkgbase be an exception in this regard? it is not an exception. it is entirely possible, and indeed quite straightforward, to switch from release to stable using pkgbase. the only nit, which was mentioned in another thread recently, is that the first time you do this you might need to use "pkg upgrade -f" because pkg sometimes thinks release versions are older than snapshots. this only needs to be done once, the first time you switch branches. > While delivering a limited or trimmed-down OS with pkgbase is certainly > possible, the same is true when installing from source. In fact, upgrading > the world and kernel over NFS is often even faster and less resource > consuming than using pkgbase. It would be a great loss for the community = if > this old, seamless, and proven-to-work method were ever deprecated in fav= our > of pkgbase. we are not removing or deprecating installworld. there are no plans to do that and there is no reason to do that. to reiterate, in case it's not clear: the error being discussed in this thread is NOT a precursor to removing installworld support and it is NOT an attempt to prevent people from depkgbasifying their system. its purpose is an anti-footgun device to prevent people from breaking their system by running make installworld without first depkgbasifying the system, which will leave the system broken. as i said previously: if you correctly depkgbasify your system, you will not encounter this error message. it is ONLY displayed on systems which have NOT been depkgbasified. --ULMpEnE2qcJ3nD16 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaSG0IgAKCRD1nT63mIK/ YD5hAP4neq9HCUyOZYzmSvdzkUvW3Md5YGZcAyJPqkoBM9hxdwD/QEfgtBHxt33s Gsa0cN8PC9MAhjiEdQQR7p1+QUn3Zgw= =0vyb -----END PGP SIGNATURE----- --ULMpEnE2qcJ3nD16-- From nobody Sat Nov 22 13:06:28 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 4dDC691zdvz6H5Nw for ; Sat, 22 Nov 2025 13:06:57 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dDC6913Q3z3nt9 for ; Sat, 22 Nov 2025 13:06:57 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763816817; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SkmL+ZP5C88rMw8uMJGNeSeLSSmtY/mKFQ0SEe3q1sY=; b=dxiAw8eNxi1N+9utZzurKRs9d1VorX2qc+Zvo2bkKtvtmvXNYXXJRyS6NdZ3+yBQcd1cjr EQ3vTgReuAYU+z6fU8e8W8iILBEJTsr//JhqfWAgUwXoP43G6D3ivYd4YWmJ3bzk6SzulE SoyfjzXiQSelLRbtxEGjPdfyoZJsBQRvJWSPEpgV/XsefdYXEZqKB5snwZoJEQ6+RqbT4t +I34/qOCTbt2xGFQLXkIHGi6FRAwEh6u29wP6NrkdJRRHiTPXS3vxBKGP84Nks3XcVh5FY JDeypX9PxYFwExnDVbzb4FEcRmZ290XLaZCBCj0v5oy0zpHN2oHZTtVmFUfTmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763816817; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SkmL+ZP5C88rMw8uMJGNeSeLSSmtY/mKFQ0SEe3q1sY=; b=GpzAH31WvNaA3ND8up3ReZdJ2NZYygDQfm/yzN9yl4cY6XdQvJOHvvUueBXx1nDaWHRT9+ SHcAhYnmsnoPoD8fjVgLUijJ5CiuppBM6rnPEGiGujZZkwhMS62diUkWypBlcT7LH2Ckum dgjSrd9J//Tiw+6TgeLE9lDSCYVeTLUy0QvKuBvWsSIrPknF5BRU3fvZuu7NugdepVWI1g r7ec3kmoHkVQO0u2PY/3d/0gIj4OWuUDseyQQC/F3PI0cbBYmKx3oUK3BCbR9SgYlmZEYG 4W9HzGure5n5ULeRrQb/GNveI71VaxOF0Ob6QKHIfEY17bU1sOnwNNQzzRx6+Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763816817; a=rsa-sha256; cv=none; b=LmaeGUdeCKG86GKMcKmcL4MabQ82TFtrcXt7aqHxp79eXHWktOctuRV9+Yi3mXs9TruZy+ 0NZSOQNnOJX3RXzEnnaDNLF6fvwuwPI5z5OgSBNZrUPgZ5CkUv8fdkohcrbfYuvs9v2UME D6KWdwXi7+4bgb7IxzobWe+2/mUolUvaaTixfCEsWmDNVMCd4M/iM+bURvdz1i5ntDwK5F l1+OqPwOV5Hr4Ifr8IsQb8dKff3WNxeb6D1JjJkc3sXCd83DuwHX7aUf+h1mnubbzYzeij d4XV1xTE6COkHfB7xzc877TlAuLdzRhPQyKQiduRZ3akETL3JPNDir1GAAR4HA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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 did not present a certificate) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dDC685JHxzmdT for ; Sat, 22 Nov 2025 13:06:56 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Sat, 22 Nov 2025 13:06:28 +0000 From: Lexi Winter To: freebsd-current Subject: Re: changing from pkgbase to regularbase Message-ID: Mail-Followup-To: freebsd-current References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> <20251122215646.7e4f34e1955bca5dbf3261a0@dec.sakura.ne.jp> 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AlJ9rfq6c0/MNgbC" Content-Disposition: inline In-Reply-To: <20251122215646.7e4f34e1955bca5dbf3261a0@dec.sakura.ne.jp> --AlJ9rfq6c0/MNgbC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tomoaki AOKI wrote in <20251122215646.7e4f34e1955bca5dbf3261a0@dec.sakura.n= e.jp>: > On Sat, 22 Nov 2025 11:39:56 +0000 > Lexi Winter wrote: > > Tomoaki AOKI wrote in <20251122180931.52c1141475f5faec4fad633c@dec.saku= ra.ne.jp>: > > > I don't think disallowing de-pkgbasifying is a good idea. > >=20 > > we don't disallow depkgbasifying and there is no intention to do that. > >=20 > Currently, IIUC, there's no pkgbasify and de-pkgbasify program > in-tree. correct. there is no depkgbasify tool at all, as far as i know, since pkg is missing functionality which is required to do that. > So preparing way to de-pkgbasify on nearly final step of the installer > (just before "after-installation configurations" like adding user) would > be helpful. this is planned for 16.0, since we will no longer ship distribution sets and therefore need another solution to do non-pkgbase installs. however i expect the UI to remain the same as it is now: you select whether you want pkgbase or not, and if you choose not, bsdinstall will silently do a pkgbase install then depkgbasify it. there's no need to potentially confuse users by exposing what's happening behind the scenes. --AlJ9rfq6c0/MNgbC Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaSG1VAAKCRD1nT63mIK/ YPAPAP0Wu6zb/e57afgdkoa7iz1u4YNOvxewfwUfYen+wrnQlgD+NTbDOuyUoBUP +HvEIrzFFQlFCCj6iMzAhRoVPFDWBAk= =wtfz -----END PGP SIGNATURE----- --AlJ9rfq6c0/MNgbC-- From nobody Sat Nov 22 13:48:08 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 4dDD1y3R5Gz6H8xM for ; Sat, 22 Nov 2025 13:48:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDD1x6vbjz3tbg; Sat, 22 Nov 2025 13:48:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AMDm82A003285; Sat, 22 Nov 2025 15:48:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AMDm82A003285 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AMDm8eo003284; Sat, 22 Nov 2025 15:48:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 15:48:08 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> 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: <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDD1x6vbjz3tbg On Sat, Nov 22, 2025 at 01:23:00PM +0100, Michal Meloun wrote: > > > On 21.11.2025 21:02, Konstantin Belousov wrote: > > On Fri, Nov 21, 2025 at 09:54:23PM +0200, Konstantin Belousov wrote: > > > On Fri, Nov 21, 2025 at 08:08:47PM +0100, Michal Meloun wrote: > > > > First, many thanks for your efforts, but this check doesn't trigger when the > > > > problem occurs > > > > > > > Hm, ok. This is a data point, in fact. > > > > > > > > > > > To be more precise, testing case > > > > on fresh kernel(d8bfcacd12aba73188c44a157c707908e275825d) > > > > with PMAP_DEBUG defined in pmap-v6.c and with > > > > trivial zero check for first page at this place -> > > > > https://cgit.freebsd.org/src/tree/contrib/jemalloc/src/pages.c#n281 > > > > > > > > causes this failure: > > > > > > > > __je_pages_map: addr: 0x0, ret: 0x3087b000, size: 4096, alignment: 4096, > > > > prot: 0x00000003, flags: 0x0C001002 > > > > __je_pages_map: i: 0, p[i]: 0xFFFFFFFF, p: 0x3087b000 > > > > __je_pages_map: i: 23, p[i]: 0x308E5F94, p: 0x3087b000 > > > > > > Could you, please, when the failure is detected, spawn 'procstat -v ' > > > and dump the memory map of the process? To be clear, I want to see all > > > of this: > > > - the address of the mapping returned by mmap > > > - its size > > > - the location of the first non-zero byte > > > - memory map > > > > Also, regardless of the output above, please try this as a wild guess: > > > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > index 5b4517d2bf0c..5c6ed51706bf 100644 > > --- a/sys/vm/vm_object.c > > +++ b/sys/vm/vm_object.c > > @@ -2222,7 +2222,7 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > * Remove any pages that may still be in the object from a previous > > * deallocation. > > */ > > - if (next_pindex < prev_object->size) { > > + if (true || next_pindex < prev_object->size) { > > vm_object_page_remove(prev_object, next_pindex, next_pindex + > > next_size, 0); > > #if 0 > > > I finally found the right way to obtain both parts of report in synchronized > and straightforward way. > The outputs from procstat -v are in the Outputs from procstat -v are in > attachments, I hope that the mailing list won't eat them. > These are without this patch. > > About this patch - this does not solve the problem, but it measurable > reduces its likelihood. So in both cases you reported below (skipped) the problem indeed appeared in the case where we extend existing mapping, potentially causing the object to reuse the dandling pages after the object' end. This must explain why the debugging patch did not catched anything. It is somewhat strange that the vm_object_coalesce() patch has the non-deterministic effect, but lets see. Below is the big hammer, disabling the extension for the anon mappings at all. Again, I want to know if it helps. This is a debugging aid, not a fix. It should cause large(r) fragmentation of the process map, and possibly much larger kernel memory use, but I hope it is usable for test. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 6b09552c5fee..6a1db58d2d13 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -1732,7 +1732,7 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, vm_object_clear_flag(object, OBJ_ONEMAPPING); VM_OBJECT_WUNLOCK(object); } - } else if ((prev_entry->eflags & ~MAP_ENTRY_USER_WIRED) == + } else if (false && (prev_entry->eflags & ~MAP_ENTRY_USER_WIRED) == protoeflags && (cow & (MAP_STACK_AREA | MAP_VN_EXEC)) == 0 && prev_entry->end == start && (prev_entry->cred == cred || From nobody Sat Nov 22 14:05:48 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 4dDDQK36d2z6HB2C for ; Sat, 22 Nov 2025 14:06:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDDQJ304Tz3wG4; Sat, 22 Nov 2025 14:06:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AME5mLZ004171; Sat, 22 Nov 2025 16:05:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AME5mLZ004171 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AME5mGK004170; Sat, 22 Nov 2025 16:05:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 16:05:48 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> 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: X-Spamd-Bar: + X-Spamd-Result: default: False [1.19 / 15.00]; NEURAL_SPAM_MEDIUM(0.94)[0.937]; NEURAL_SPAM_LONG(0.65)[0.648]; NEURAL_HAM_SHORT(-0.39)[-0.392]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_DN_ALL(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4dDDQJ304Tz3wG4 On Sat, Nov 22, 2025 at 03:48:08PM +0200, Konstantin Belousov wrote: > On Sat, Nov 22, 2025 at 01:23:00PM +0100, Michal Meloun wrote: > > > > > > On 21.11.2025 21:02, Konstantin Belousov wrote: > > > On Fri, Nov 21, 2025 at 09:54:23PM +0200, Konstantin Belousov wrote: > > > > On Fri, Nov 21, 2025 at 08:08:47PM +0100, Michal Meloun wrote: > > > > > First, many thanks for your efforts, but this check doesn't trigger when the > > > > > problem occurs > > > > > > > > > Hm, ok. This is a data point, in fact. > > > > > > > > > > > > > > To be more precise, testing case > > > > > on fresh kernel(d8bfcacd12aba73188c44a157c707908e275825d) > > > > > with PMAP_DEBUG defined in pmap-v6.c and with > > > > > trivial zero check for first page at this place -> > > > > > https://cgit.freebsd.org/src/tree/contrib/jemalloc/src/pages.c#n281 > > > > > > > > > > causes this failure: > > > > > > > > > > __je_pages_map: addr: 0x0, ret: 0x3087b000, size: 4096, alignment: 4096, > > > > > prot: 0x00000003, flags: 0x0C001002 > > > > > __je_pages_map: i: 0, p[i]: 0xFFFFFFFF, p: 0x3087b000 > > > > > __je_pages_map: i: 23, p[i]: 0x308E5F94, p: 0x3087b000 > > > > > > > > Could you, please, when the failure is detected, spawn 'procstat -v ' > > > > and dump the memory map of the process? To be clear, I want to see all > > > > of this: > > > > - the address of the mapping returned by mmap > > > > - its size > > > > - the location of the first non-zero byte > > > > - memory map > > > > > > Also, regardless of the output above, please try this as a wild guess: > > > > > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > > index 5b4517d2bf0c..5c6ed51706bf 100644 > > > --- a/sys/vm/vm_object.c > > > +++ b/sys/vm/vm_object.c > > > @@ -2222,7 +2222,7 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > > * Remove any pages that may still be in the object from a previous > > > * deallocation. > > > */ > > > - if (next_pindex < prev_object->size) { > > > + if (true || next_pindex < prev_object->size) { > > > vm_object_page_remove(prev_object, next_pindex, next_pindex + > > > next_size, 0); > > > #if 0 > > > > > I finally found the right way to obtain both parts of report in synchronized > > and straightforward way. > > The outputs from procstat -v are in the Outputs from procstat -v are in > > attachments, I hope that the mailing list won't eat them. > > These are without this patch. > > > > About this patch - this does not solve the problem, but it measurable > > reduces its likelihood. > > So in both cases you reported below (skipped) the problem indeed appeared > in the case where we extend existing mapping, potentially causing the > object to reuse the dandling pages after the object' end. This must > explain why the debugging patch did not catched anything. > > It is somewhat strange that the vm_object_coalesce() patch has the > non-deterministic effect, but lets see. Below is the big hammer, > disabling the extension for the anon mappings at all. Again, I want to > know if it helps. This is a debugging aid, not a fix. It should cause > large(r) fragmentation of the process map, and possibly much larger > kernel memory use, but I hope it is usable for test. > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 6b09552c5fee..6a1db58d2d13 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -1732,7 +1732,7 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > vm_object_clear_flag(object, OBJ_ONEMAPPING); > VM_OBJECT_WUNLOCK(object); > } > - } else if ((prev_entry->eflags & ~MAP_ENTRY_USER_WIRED) == > + } else if (false && (prev_entry->eflags & ~MAP_ENTRY_USER_WIRED) == > protoeflags && > (cow & (MAP_STACK_AREA | MAP_VN_EXEC)) == 0 && > prev_entry->end == start && (prev_entry->cred == cred || > Independent from the patch above, please test the following enhancement to the vm_object_coalesce() patch. There, I have some hope that this might be a proper fix. commit 012ea1ce604a59d790661c25656c1c641d33d6ec Author: Konstantin Belousov Date: Sat Nov 22 16:02:50 2025 +0200 vm_object_coalesce(): fix logic to detect coalesce possibility, simplify diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 5b4517d2bf0c..d59327cf22ca 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -2188,9 +2188,14 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, prev_size >>= PAGE_SHIFT; next_size >>= PAGE_SHIFT; next_pindex = OFF_TO_IDX(prev_offset) + prev_size; + KASSERT(next_pindex + next_size > prev_object->size, + ("vm_object_coalesce: " + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, + (uintmax_t)prev_object->size)); - if (prev_object->ref_count > 1 && - prev_object->size != next_pindex && + if (prev_object->ref_count > 1 || + prev_object->size != next_pindex || (prev_object->flags & OBJ_ONEMAPPING) == 0) { VM_OBJECT_WUNLOCK(prev_object); return (FALSE); @@ -2222,26 +2227,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, * Remove any pages that may still be in the object from a previous * deallocation. */ - if (next_pindex < prev_object->size) { - vm_object_page_remove(prev_object, next_pindex, next_pindex + - next_size, 0); -#if 0 - if (prev_object->cred != NULL) { - KASSERT(prev_object->charge >= - ptoa(prev_object->size - next_pindex), - ("object %p overcharged 1 %jx %jx", prev_object, - (uintmax_t)next_pindex, (uintmax_t)next_size)); - prev_object->charge -= ptoa(prev_object->size - - next_pindex); - } -#endif - } + vm_object_page_remove(prev_object, next_pindex, next_pindex + + next_size, 0); /* * Extend the object if necessary. */ - if (next_pindex + next_size > prev_object->size) - prev_object->size = next_pindex + next_size; + prev_object->size = next_pindex + next_size; VM_OBJECT_WUNLOCK(prev_object); return (TRUE); From nobody Sat Nov 22 15:01:39 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 4dDFg252SYz6HGj6 for ; Sat, 22 Nov 2025 15:02:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4dDFg212nSz4B1W for ; Sat, 22 Nov 2025 15:02:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Nt54uf1n; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763823713; bh=imrqaSgzbFO+ZuH2QoBlL75h0ohq6uNGkIPwQOPjo/E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Nt54uf1nH2J3uPu4jphwUPWaBKrL4bQKTNlBYAsfI5BwWTaoPEoleq+JXhAQMNv1zb7lq7GJVgXjqrPoz6RaB4bZsVX8R0ifeeiM0iUbuaZ4HeHrou1ozbopH+DySvBmlcQ430QYhA0zwE5Bf06fc8TYpFsmAaHkcAyrTl7YqpjpfqH9NP275rC1p0SwQX/rjR/9c1+V6I33dU1VyQV0/rmK96/77mdorTc3NbWhoqzsYvlVyAzxh4zaCKHgk5AshLzS+u1u7SgeuSC9YxqDCTMJjIy7XLCShlLMHaDyDV18haTJWkqfRTqXrCV6Nwgz3fq0w0s0lLxQT3kDkXVAtg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763823713; bh=/VENqDKZPn5ja8dEngmKeOtT3390lvyqvnNS/oYfULw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=W1LBeZPVEuB4+AuX1OemJyMZuTq10FVpPRrgTXabf9qgd5t8LLJtb6JjZhFi7huuVlq9RA0oK7hHna16NuefyhEgdngBjNJkI2Y1RqxzPTm5S92fPTjqRTXVZFon4C4+3Zd2+Qi4v7kUL4l2IzOtQVkrH8YT29nhI588S7E10BpZPTnkPS1KcyJNcp5RCau8R9gSRaRwfy8VzQ866HU+iCFSg0m1IEukPvsS0ziD7BFywjqWSOMoj1n8+uB+1NTNFEoLQkU9E2PcC4UcyuMsWKOHWEQLj0YlyRGU5XI0gcGpQ5GMzbt6Jz2JEmGoGOqVWqaQx0vxVIYOBg/DsCc3Yg== X-YMail-OSG: Pky9mNEVM1lRoWqF0a1TQ.yfljtCnS2ijB6OO6lroLCqaZv88Lmw8.p4r2qrKiv divOGwEBLTPNWYCjQ6DM1hpSqh4VlR0m52uyFpKuZMbaK2tV5YCTf5x4nH4LOHW4JVjV9C582PoJ nF10xBDjK81ixcdZJrx6yB4PFtQv104474D8jTZTWVKunlFz0amsC.PvlBYIJB6crSnXkTNUPgRI fUmNSnJPjBW19ZKkxiC20t4Yip5Ln2B4uXO4ZSaI6PZHY1xnYnnG8Oq8QvWAUPMBHVKUAqCbRInu F7v6ABucTjE7DkbB0xsq1hzploXsl9f4fy6mjEFgYuku4SOrTW8cEYEx1Iaa6Nz_EAV5DqcQFO6W o2GbNai6D0CthT.nNtc1DFLcZK_aoz8QlJVWcXdiGlz0GwUpnWnFtEALqR7MRy98q.SsknRu62I9 KL.ICsQkZSrSWU5i6mBRtEdWeXZMj0S49W0RTbBqtfm1d1Ni971Y6qHVLvU9QraW7KOwwvKQ8A0l ls5IH9drb6uDdPiQjaf9hNvY8Q3UJcDfEIUYe9teWihuX5u1UAcbMUrrE6TfqnFn96iifKzuvtIy 9dO6Tw6w8GFvJ6u9ir35gBdhmjvxEv9YSUQ8lZ4dzq6bt7djaYLnOMeM_m0Ijh9Ad6Nj_7aJe7b2 G13gQ2ggti3yj1wGkDPWmtom9pMX5VBdHirE6o45s2NvsDqtkVFYxhLwVkNCcxzAOQp1UeV.SRuX VxCsYn4YiO9hINqpAr9tVZelz0eUQOLzFcEtF.K3aELCgBt0LW75vIvw0XD8_ubu2XcS52rV6DM1 trSn1mHcmrs.o2Gwo.XpZOetOH1qeKSUuFjWZy0MSOBTqYPUcTB7wDPxDYN5RWkMHoLC8yr65dhJ v1n_inbJQimTZ35_qnw0BIKCa.j6i8FgBiWqoxEuBF3cHNIja2ANwBLVzjvnEDkO.yydFueIGmEx CN0VOV8hhkPYm8tyKVXM4o1HzOxvD2ln3K1uWbkQSzCcVjGGXLAAvgwa5Gg9AlrX.GOpPxzDum0A gx2uPkSN8xy7zqrsKTvXCfmQeycHNT1U10L4QHS_XLspdUs2oCdj269lXv5VCHL1J6Fi1Rsu5Gsw YPjZ8pD1Pmjh8JZvbNiQJM8RZvsKChS8iBUGHnQlIdC.o1RH4FtBuC1mn0AoTmjIzlWQkiqTmI4k vnJkF1tzR56sguVGyy67X46viTVQrti_7IF1BalA608w4eR8SuYHQW2qO4sBywOW2I5LgIhbhBNv KeNktnoTrtiQkRM9pC6dnKGXSNLqyzpwz_u4fWfchYQptfP1XMlKV6vxJO9f5l7wl6J9nsfnDqA6 zoNsSzOjMXyoDj7Uorz6q3XnG6dauV0TgUOjlvzmUtija3lQy1.U8PIljJkoLPPXIqPjOyd9UQNm dFpgYmrTDvv9ewo70gv.A6olZTb8Fy16SVgdP2p98MK5bt9vQ2N18N1yN0Fd7nSwHtLFgYFlkVvN _nhyoxHqiGV1OG4YYjzW4376bTCJ.boLXQ.hd_scuEa62z0IDLMdIiZHE2w4KyvwBePcCM8HsiBr OAMhZ5fZ47zu2DThCdX2Ac0lMrWkbdNp6q..sbZ6jn5KFCGiJpE_DIY3ZmYv8_QtcfpQC0ROh2s7 hX1KBW5M2YpK.BRiHxEr1DQNUVPUe6jMHKrHTlWKNppIbOMgx05Jpx3PxaVDbvOUrM9mvgmiN79V LyRJVw2JI58bFXqOfYEeeo6wOI6n9BSHlQ9vPi9GkcBHizAdw3v0IcRyVLJ0_vFjv7mbm0MVOcJz 90ayJKSOH46H7KUGGKXYRUz7oYkq05wWgs_EaDTjygO0qa6MLn95XTBWzdDzczpZOOmSUob.fyhC Gq39r9GMC30n1lnbitwjfYFMAp_HvqAwwfULEWl0j4WzXxv6PMHyUl.bqhxUt.UG9RNzLRyk_EgF StMPqZ0fjJFlyWgHwpRWabMhe6DqQOADExugvfAhYxNcJyt870.TPQUIs.on0tGW8YZwd.iL42Ue .RIMfoAgvGI07csBXjP84OJuZ9LOJ6TrMw8..1YxNPsW6DIgE9uUqhgfbx7PxWDUzCZOoq0XLrHs Y4VYSH3tJVCKCnZ5_y.aySXiByMTawHXw.B9vSiVQYiX38kV4E.voBQ1hCD.QjDD_WA0tiBysAr. WEzpdu77btQZeJ6nh8hLYM8_FOokqD3XmRg6iSkQR.8Msda.X1Ts0Skj25BXL3V79BKMZbzqqAJn RxRQG4FCZDCnPjnK_Eqog_2UJoYvTR3SAcxmpOVtgR4v67MOCrC0k.2Aw.Iq9UMtz2hVX6vtQ4go J4hgra7HV6wdg9eI- X-Sonic-MF: X-Sonic-ID: 35fcad91-5a31-4a73-bc7d-b76093445ef2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Nov 2025 15:01:53 +0000 Received: by hermes--production-gq1-fdb64d996-5ct4t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f404138db52f37493806fb20ecf21354; Sat, 22 Nov 2025 15:01:52 +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" [ junk:true vs. junk:alloc,zero:true ] From: Mark Millard In-Reply-To: Date: Sat, 22 Nov 2025 07:01:39 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop Content-Transfer-Encoding: 7bit Message-Id: <1D4D3C5A-B43E-4809-9460-169536FFB2B2@yahoo.com> References: <877bvthymv.fsf@panix.com> <13E753F4-84F8-4ADB-96B6-908897D6971C@yahoo.com> <3174F751-9853-4697-B0C0-98B54518A69F@yahoo.com> <463AC500-C7C7-43FB-B5EF-332CEBA3D944@yahoo.com> <3E0D6079-0F5B-463E-94D4-37506A837D33@yahoo.com> <05479AC8-C8EB-42A3-9A54-2CAF687023D2@yahoo.com> <422A55DB-E005-4DA5-89F3-52879F35F6A4@yahoo.com> <87fra9fd4m.fsf@panix.com> <878qg1f8wz.fsf@panix.com> <265F191D-5400-4A9D-BE99-F060770B5DED@yahoo.com> <32C6B8A3-E390-48C8-8454-753511ADDF57@yahoo.com> <5A0EABFD-A84F-444E-B41A-BC2F9584FF99@yahoo.com> <0542BED0-5446-402C-8924-5EA745B8E51C@yahoo.com> To: Konstantin Belousov , Michal Meloun , Warner Losh , freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from] X-Rspamd-Queue-Id: 4dDFg212nSz4B1W In the armv7 chroot on aarch64 test context, I tried: # env MALLOC_CONF="junk:alloc,zero:true" WITH_META_MODE= make -j8 buildworld It still failed but the data pattern observed was different: no longer any 0x5a sequences (jemalloc's value for junk for freed memory). For example, mostly 0x00000000 with some 0xffffffff mixed in. I've never seen the 0xA5 junk:alloc pattern in the failure data. === Mark Millard marklmi at yahoo.com From nobody Sat Nov 22 15:30:08 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 4dDGHf6Rpsz6HKKl for ; Sat, 22 Nov 2025 15:30:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDGHd4GWKz3G71 for ; Sat, 22 Nov 2025 15:30:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-8b2ed01b95dso299863385a.0 for ; Sat, 22 Nov 2025 07:30:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763825420; x=1764430220; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WWfL4jr7NQopSLKoQ29BZfFZN5R7s3hxcben1TNundU=; b=QxCg6OcExSTd4bp/mCdSnzOThTm9Px9A4yOnrYRPcLYny6Luapb6FvN3Bm+W5yUBGE TNm8R9onWgMGudHyGOuEnMxW8knYnsLoWyTVJRVO8R+IToJv6oSDzjQG7CYvpRe3Aoy+ n9QX2g5fdRHbzQL3oB+GZ2w6gCN1VDni9ouVnJQhW7AX+q32GlOtt48E1V7PG/zhwZXt 3cWMCug4CvjSPokKJ/KPTbZZ8NN5tfGfUtV8VNw/tAxqMZslef1isOOiaFJyFw+ex+Mh EJkNG2lWqav2/VTxpy9c8Wm47dt69B25YQGFIqgOZ/edYHY9BySoGlnkBTa6/8NIbD5O V1dg== X-Gm-Message-State: AOJu0YyDS/w6pN/zi0iH/cmwbz2NhqhZR5anwS/TktQ4IXQavneF9fGh rSBet5lkkJKfG+ARXZmISi/1a4XutAlA7NqAQ3hx0x/fo1WZTZpPQiBbt2Ebc/SPCkhiZ2x6BF/ j8XrBPCGipyD6BOmkOOPwZg7v5xRnQbVe1HTrocE= X-Gm-Gg: ASbGncsNMO6yIXmYBmj2kskIdfIvrRUBA/ucy6T8BfCndxQPaLh+S/vmvw8bWvT09vR ywn1/0vqZIoucy1NTsxBuklnoog1BO9VvEPq5b2NMeIQ/X+998M3WyGwVXuUAn8B0Q38xFSl6pk 7rkQvaPBmS9xa4Kh7zCkuiLRs025ElsDNGAERc0ivvNqjNVkJpvDv46VWmwFYG3O/2AFuC9K5df StRnmzAJJB00LiUKRedmKjKIz0oPo9m+gcelxHrIOxQYKLpD3miFeKg1phJjhS57jQJ/FiYRrOZ jFI5rjwYfgl0jPs00gkBIebbdaHurQ== X-Google-Smtp-Source: AGHT+IE+/sMiFbEAMGO3RUEPFSRv8MBln+8SXC1RHM3veGNmqHmQXPMHpZXFP1POUjsfzbfDz/CZlcDpBwnwdVH20i4= X-Received: by 2002:a05:620a:4141:b0:8b2:e177:dda7 with SMTP id af79cd13be357-8b33d4890eamr735805985a.81.1763825420240; Sat, 22 Nov 2025 07:30:20 -0800 (PST) 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 References: <234ae3a0-eed0-4c33-ad3c-9d5811549562@uitveenendaal.nl> In-Reply-To: <234ae3a0-eed0-4c33-ad3c-9d5811549562@uitveenendaal.nl> From: Adrian Chadd Date: Sat, 22 Nov 2025 07:30:08 -0800 X-Gm-Features: AWmQ_bkKDK_oHUEYEI662jOeVIRBPGSc-muUDkcOSBs2DiaMYf-2IV-Wnt_C7Fo Message-ID: Subject: Re: HP ProBook 6550b hangs on kernels above 14.0-RELEASE To: opensource@uitveenendaal.nl Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009e8e600644309b8e" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.46 / 15.00]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.81)[-0.806]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; NEURAL_SPAM_LONG(0.24)[0.244]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.174:from]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TAGGED_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.174:from] X-Rspamd-Queue-Id: 4dDGHd4GWKz3G71 --0000000000009e8e600644309b8e Content-Type: text/plain; charset="UTF-8" hi! The observation in the post about it being ACPI is also very valid. Can you share more specific details about the hardware in the laptop? It looks like I can pick one up cheap on ebay, and if it's an ACPI problem i'm likely going to need to add printf debugging everywhere to give the ACPI maintainer some more information. ;-) -adrian On Tue, 18 Nov 2025 at 11:21, Michael wrote: > Hello, > > ==== > One of my old laptops (HP ProBook 6550b) was running FreeBSD > 14.0-RELEASE (amd64) perfectly fine, but upgrading to anything higher > results in a boot that hangs at the line: > psm0: model Synaptics Touchpad, device ID 0 > > A while ago I tried upgrading to 14.1-RELEASE and run into this problem. > Back then I decided to wait, hoping this glitch would be ironed out in a > later release. But today experimenting with 14.3-RELEASE and 15.0-STABLE > from 20251113 I got the same results. > > It would be great to find a fix for this and would like to help > troubleshooting this issue. I'm not even close to a kernel developer > though, but perfectly capable of gathering all kinds of information (I'm > a FreeBSD-user since version 4.4) and help testing. > ==== > > This is what I posted on the FreeBSD forum. The post is here: > > https://forums.freebsd.org/threads/hp-probook-6550b-not-booting-14-3-release-15-0-stable.100065/ > > The conclusion there was to try again on this mailing list. > > I tried kernels 14.1-RELEASE, 14.3-RELEASE, 15.0-STABLE and the most > recent version I tested with is > FreeBSD-16.0-CURRENT-amd64-20251110-dbb34d496708-281771 > The problem is still there. It seems the system locks up since scolling > back up doesn't work either. > > I wonder if anyone is willing to look into this. The offer to help > troubleshooting this and test a solution (if any) stands. > > Kind regards, > Michael > > --0000000000009e8e600644309b8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi!

The observation in the p= ost about it being ACPI is also very valid.

Can yo= u share more specific details about the hardware in the laptop? It looks li= ke I can pick one up cheap on ebay,
and if it's an ACPI probl= em i'm likely going to need to add printf debugging everywhere to give = the ACPI maintainer
some more information. ;-)



-adrian


=
On Tue, 18 Nov 2025 at 11:21, Michael <opensource@uitveenendaal.nl> wrote:
Hello,

=3D=3D=3D=3D
One of my old laptops (HP ProBook 6550b) was running FreeBSD
14.0-RELEASE (amd64) perfectly fine, but upgrading to anything higher
results in a boot that hangs at the line:
psm0: model Synaptics Touchpad, device ID 0

A while ago I tried upgrading to 14.1-RELEASE and run into this problem. Back then I decided to wait, hoping this glitch would be ironed out in a later release. But today experimenting with 14.3-RELEASE and 15.0-STABLE from 20251113 I got the same results.

It would be great to find a fix for this and would like to help
troubleshooting this issue. I'm not even close to a kernel developer though, but perfectly capable of gathering all kinds of information (I'= m
a FreeBSD-user since version 4.4) and help testing.
=3D=3D=3D=3D

This is what I posted on the FreeBSD forum. The post is here:
http= s://forums.freebsd.org/threads/hp-probook-6550b-not-booting-14-3-release-15= -0-stable.100065/

The conclusion there was to try again on this mailing list.

I tried kernels 14.1-RELEASE, 14.3-RELEASE, 15.0-STABLE and the most
recent version I tested with is
FreeBSD-16.0-CURRENT-amd64-20251110-dbb34d496708-281771
The problem is still there. It seems the system locks up since scolling back up doesn't work either.

I wonder if anyone is willing to look into this. The offer to help
troubleshooting this and test a solution (if any) stands.

Kind regards,
Michael

--0000000000009e8e600644309b8e-- From nobody Sat Nov 22 16:29:05 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 4dDHbk38L4z6HPv8 for ; Sat, 22 Nov 2025 16:29:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4dDHbh62pBz3PLT for ; Sat, 22 Nov 2025 16:29:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Z1X8zcNa; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763828957; bh=L75Ghx5Z8Oj1kBC4cxnvk4kT5472Fsm4zAoCwSq1VY0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Z1X8zcNaO6D7jA8SZgdUmFTMSKVAB4W5PyR1Lkr5lfmDB/XhEcdy/aU62bFFJunljczeTtyjTNDUv/vjiugQVb4zCbe7aKZV8ObovOfUJ0jci1ubiysWnvFd81yQ/7arkEh4cHIJGphhKwEfWlcS+ihIYJyEfSwJ1+HPzkaG6IquJfCwpDCGmGeZ3iZRf4B6dM7XjDFIZRAQjMp9KqQcyEkzknny+SQiWRu7X+DEYhMTEuWPq7HMe0/4EviVXA9Wk9HYDnT8r+MsDVoypaXLBDCOAW9Uh6T9YQeMWbcJRsukACp1jJxsdUlv0Akga1bEn3B7hwbPPLalicPGtm81Fg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763828957; bh=0I1XVqzT2QcLqn08ZV7UJyjLngSpQhs3mBUWW8a69OW=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=f6HxOBwaTm9OI8IFFMenEzx9Xaxts88V2YDx0dyvrdx3YwRgkeEhrb6W3D1GcFtjJUEoU5i/aNWdXpVobEnlTiQci0+4qJjnGHPF/D7s3smcEV1yb62xU9H28T8tEufw3EC5dUgmqIoGrWZjJ4/s2/BPNV3kJ9C44XEGZuZo5coilI1zav6nm7PjCW1TucDoPPhDbET3Vtz1tR8rZHfMdaVMWNFw2a2e3mnA8nM+Mrj2w1NBhz3NoKZwYxsb4sufxEd8P9uhlQFCXnHDTE/wT8yZeg/Huh3bzhJJ+LMV1yBfPYfC6yLOjwXNsK/ElE9yA+ca3lReWkKta9ZPrnGTQA== X-YMail-OSG: kjPD35oVM1nNd7Lqgs7ErCbTsutKJGIeesJr6cV1qy81yLlKV.wJ6ZBj0a1IhGY odhT9RzWZ32evJvZEk0V8pKkufzh81eOO9dK5wah1F.SklzDvL0BG56yd88gN1QsZmyEAAIun1ys oL0Jr7aMCMAiSgF9IyBdml_6nF33URugRXt.MDTRLQIP9CI1bu44YEh2iknHmWHea8FOCPYZlP7u iEYHKsatCLMdPFe4UtoA7W_CZhvjQkRi.ikjLFWW8Ad5rkG8dees25g2Ok30b7AHJ.ra8yz3jFqv TFQOq3UNI24rOTxE6spp0gOAN6kgJP6DvMRCo5J_eR3XIe9BKiYcPf2Gvf13UTwVhhZ3f3YDdWrH 7KXVe5iDPdrWCymr26hnO1noDgqUGsgboip2SwhloXd0rqeDPARjd96NYLoWh_4PiApsISLpPE.U PspyYiFfh2DsYTml4UHMjWlSk7r_V1O_uyb2Wa52uRe6OQogHNysEv0XgeFydvwdTRj0uUKy1PEZ H2IXRFIYaG6CvFCFvkBpUQQYMb2RZmAHCRbnrsqIGCEkwERXo.oGR3WgtfHYSVqqRZ7dEItpzdvM 2NfqTvshn_dV4cDNMjs5zigSENZhlUXImqV5tKmJBQCuWLFFkdXcxfi3EVtUPG0.6VPc2t4z3dVD b9_rr6NsaOTQJf8UQG3ZvAfRxncu2mPXQlnrJG7EJDOMGRAKSVTql9XnE0AovzKwcTTGxiHhC_k1 YisZcBBtF.VOwr3ZJ1NBxGLkaQQoOKvnBY57Amn4455WyglZ8ObI5hil28KAu2CERsxahAIK1VkM tS0AtD4valFLcLO2vmzwc84TQ.LMk_5KeHJUVLAUquMYuBvSv6INPowSUBY_UBtcEMw_zdIfbJ5r 7lkHBqmivJNX825OiJ3Dzs_wPZdfy2XcwGpuWh909UioSP28ySmjekKQMGwSGPZxCpoQM.KuoCHy DZeX.qh3rurTwxKD03lb6oHep6XKMi5xxAL1B8.HH124G0HYZboXYkAK7k37YBBj_LvRHyGXe3TG Ym2fN7De7mwP4a4nJ9gfEkh2wSVJyoUJ6eC9KFQmVRZ.CkMyE9WQyQf17extU8sDGVDQ6BvnVZQl yHsQ.aGbEkdeIXxLU.HsZJ8x3G9RQwCRYgQ1mjQmRjvrSEOt95onDl5XMGDFLfN_2sfVXCnKq6.p i0w.TIaqmGPQJAcR5ClUMrS3olz5JVN_M4EtBOHyUddm5lVxOGqwOy9lTTraEly_Z1uxOZX2eTPw .s6kBml4JOPKgELEVHoT7B86fWqKgph6slf8X0DgWB6KczdAtMb6PnJRXiA6rvYIER6NemypQktx 8W1Sbb0OZUt8ol3.GhVaAnWgB9e7IU6crZ3v1cT0uq8B3rLI3JwhZ5NBM_Rj.ep.xuU1sONCZCzn aqvU1amdmpOCtHlUJ6DNPYHZ6j1rY5UUg6YJkDztju7s.HV5BvqGNWDclyhbuY_rpJeybZ_lUA7v fMneE6SGf92w_A1YWqIyFQel13ZbiCAn2FpPwGC3yeq_Ut7c6R4EoBgW5wYO2EH_93ib_vX2dE_n fXJNYXzdAbbOmeV9qVtMvMCOQR1ZKowLT8e.YFCAedmahJHTgAXA2uxVCIJ8bks0byg7s2CpijJX hXdlfEhe5RcLn6H6mpEowmu26mylzjl7x7FmbgkGbd9dm2HlJduDq85DAI28pMu.yo9HuhETt8o8 fyfCNxfmQpgwDNMIGphfYlBbwDgEs2VybpMLGuntNCuSzC8w30pdzN_o86_0WmS2nIgjGPZ8hlXX jJ0Lkt3E1DMK7voKl_7yVpxejLg2MjbXXzBUf9IqxfFVM6KgrisPULePRras1WUqabcF940Y4emQ ptRWJWWnzwRwH2iym.HpdX.T5mJF3KkzNiPPgLQZvQ1p6djo_RZiUJZLsfcTgfKERV1q4sgRqyzj nwLE28O2xsEkGUSlTwlHOyxPlT8dqgIs2A0HfJ7L4PkZZwKj9buaYi4apJvSMPnOzJelpnfoVfwz iH8Ob9RXMEMPoWb.zOgRdiLe.NTcn38tT7Is_T.vfdu3aOjj_OIsRZpQa4mjfnKyM.X1wPJIFXm6 r2GqIRcHbS_gag.virxE534_ONE0kZ.umgIBPK1gUus4Y20zjl.EgAUc6UdaBnkLV9.DwS5fLNes DryiX4a88_N1sBfErGRdHYqcrw9I_94.HG695YauHDJywbHPNgSSLXnIx2U_zCYD.I3lBTkoXPO8 S4hgD0TM6UPQJT_SYBkI3pYTGdUwvWQU9ahiVNj8T3Cs377iFYDHHbNbGXYduq6sn6yTQ3h1H7oi p5g7g X-Sonic-MF: X-Sonic-ID: c8a369a6-eacb-4a55-968e-fef533c57271 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Nov 2025 16:29:17 +0000 Received: by hermes--production-gq1-fdb64d996-whpwx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fd254b7bbb33c2c8dada4b7311d19005; Sat, 22 Nov 2025 16:29:16 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: jemalloc/kernel debug context: panic: vm_object_coalesce: obj Oxfffff800090a27c0 next_pindex Oxf next_size 0x4 obj_size 0x19 Message-Id: <0FD24831-875B-452A-8335-2C9EF0AC7049@yahoo.com> Date: Sat, 22 Nov 2025 08:29:05 -0800 To: "kib (Konstantin Belousov)" , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <0FD24831-875B-452A-8335-2C9EF0AC7049.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.43)[-0.434]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from] X-Rspamd-Queue-Id: 4dDHbh62pBz3PLT No serial console so a summary from a picture (expect typos): . . . ue0: link state changed to UP panic: vm_object_coalesce: obj Oxfffff800090a27c0 next_pindex Oxf = next_size 0x4 obj_size 0x19 . . . vm_object_coalesce vm_map_insert1 vm_map_find_locked pipespace_new pipe_paircreate kern_pipe sys_pipe2 amd64_syscall fast_syscall_common syscall =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Nov 22 16:37:19 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 4dDHmv5rrDz6HQQR for ; Sat, 22 Nov 2025 16:37:19 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dDHmv5BCrz3QMn; Sat, 22 Nov 2025 16:37:19 +0000 (UTC) (envelope-from mmel@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763829439; 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=Q1NxrJLZ0duk+WdtJp/95zEYQErWHlacrV17lvFMNeU=; b=H8E+0+MJLBqzyduMVjqb9ggeDNkY3B1Oi9cDNt+fwNzqijETvkzkxv7CKbxZTBQUAmzHl/ ZAQy9W/CcCKcxCOvVFW4NqXvdDtY2BioNZLCGBqX1EMp4c2ZYYL5gmY8P3ujVFXaHEeX04 UpEMqfqCDvFVJXJm8f0V5JhzAbeGA9c03Ul3y6AzUzHV5ekGx82BRR0+zIOE1fqKBFHAiC E7GZ6naEytCk0+6NCmlY+hsPHEdOzk6bcFu4B3Q2KvExxTxj/UjvrRkpKgPJY9qwI35VWw 8wieVQU62mFUcjBYu3w3wdPaTC7t+V+ejSYZyb3aK0opS5dhep35TYj0VTHv/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763829439; 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=Q1NxrJLZ0duk+WdtJp/95zEYQErWHlacrV17lvFMNeU=; b=pb1m7tzQ93Co5TtYD1oim5qbkczP8rM19a75mlvrY0teUG3YtWatNT0gr5ni3z2U9noAaM 9XSLZJD5V6B6lunVYBjshOkWhwMbfYGRR1x2x8dr9Y/cIkg28v3VCPSKPEdBEqhcDoyfv1 6Ue+abEwPS2ZXgdRCrDgqzU5QbofU/QQoJ7O3VI4h6Fexf3OQEe2j2VGQFGAOlK8901oHK xmsCs6RhC49LPl/dlBuJdUwMoeEyvy/CtdP+7LYgXfW1gK7ZuBitqWAgGHdAaMDhFs4ijz T44YuhbDwCFD7u4IY56EXTSrafD6Bc/yPD561pnHDwFO2ED3lN/LJn60UiEy/A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763829439; a=rsa-sha256; cv=none; b=oUGQEUSV2XrLqmICwjaqGkn5BM76KVLJc9oponHCyQgF9YBKZUQmfA9coi+OzGoa1tNZpT 8eLN41v20xi6opB954ceRyzPvRQWcQjgwV6uNV1gsLARXtkgzIKlCEIu+k2gRlgrh1BTyr hjm4SDRiOYDt5c80Um5WPbSJFbSvMQ1bzUA4llK7NfH8i0DfkrwH7QaRqg4TX1gj8F1cNQ 1jfhJVxsfn9j+bY2XFY24VbrsAwVgQD8Zb+6275AgaI+Ij6EYyscZkiBNoQPqs/pO8MbgA anZPIUkkUGMH03PQamOKA+cB0cyvqq8gvvjjErd3SpiZTD3gK7nd2IRzoT5i/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (lety.radiolinkplus.cz [109.205.241.143]) (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 4dDHmv2Cybzrlj; Sat, 22 Nov 2025 16:37:19 +0000 (UTC) (envelope-from mmel@freebsd.org) Message-ID: Date: Sat, 22 Nov 2025 17:37:19 +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 From: Michal Meloun Reply-To: mmel@FreeBSD.org Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) To: Konstantin Belousov References: <8657a2f4-cb32-49a5-bbf6-cd5a4394c7be@FreeBSD.org> <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> Content-Language: cs, en-US Cc: FreeBSD Current In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22.11.2025 16:40, Konstantin Belousov wrote: > On Sat, Nov 22, 2025 at 03:31:24PM +0100, Michal Meloun wrote: >> This patch KASSERTs almost immediately when the system enters multi-user >> mode while processing mmap() syscall: >> >> panic: vm_object_coalesce: obj 0xc73ddb28 next_pindex 0x13 next_size 0x5 >> obj_size 0x176 > > Yes, the assert was mis-placed. Please try this variant. > > commit 2b1a1bcd2926bd89b8422c665b0aa411e29c883b > Author: Konstantin Belousov > Date: Sat Nov 22 16:02:50 2025 +0200 > > vm_object_coalesce(): fix logic to detect coalesce possibility, simplify > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..9bb4e54edd96 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > next_size >>= PAGE_SHIFT; > next_pindex = OFF_TO_IDX(prev_offset) + prev_size; > > - if (prev_object->ref_count > 1 && > - prev_object->size != next_pindex && > + if (prev_object->ref_count > 1 || > + prev_object->size != next_pindex || > (prev_object->flags & OBJ_ONEMAPPING) == 0) { > VM_OBJECT_WUNLOCK(prev_object); > return (FALSE); > } > > + KASSERT(next_pindex + next_size > prev_object->size, > + ("vm_object_coalesce: " > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > + (uintmax_t)prev_object->size)); > + > /* > * Account for the charge. > */ > @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > * Remove any pages that may still be in the object from a previous > * deallocation. > */ > - if (next_pindex < prev_object->size) { > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > - next_size, 0); > -#if 0 > - if (prev_object->cred != NULL) { > - KASSERT(prev_object->charge >= > - ptoa(prev_object->size - next_pindex), > - ("object %p overcharged 1 %jx %jx", prev_object, > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > - prev_object->charge -= ptoa(prev_object->size - > - next_pindex); > - } > -#endif > - } > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > + next_size, 0); > > /* > * Extend the object if necessary. > */ > - if (next_pindex + next_size > prev_object->size) > - prev_object->size = next_pindex + next_size; > + prev_object->size = next_pindex + next_size; > > VM_OBJECT_WUNLOCK(prev_object); > return (TRUE); Unfortunately, that didn't help. I will try the vm_map.c patch again for confirmation. From nobody Sat Nov 22 16:53: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 4dDJ7X0wSkz6HRYP for ; Sat, 22 Nov 2025 16:53:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDJ7W3sRXz3SdC; Sat, 22 Nov 2025 16:53:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AMGrF1e012994; Sat, 22 Nov 2025 18:53:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AMGrF1e012994 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AMGrF3w012993; Sat, 22 Nov 2025 18:53:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 18:53:15 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> 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: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDJ7W3sRXz3SdC On Sat, Nov 22, 2025 at 05:37:19PM +0100, Michal Meloun wrote: > > > On 22.11.2025 16:40, Konstantin Belousov wrote: > > On Sat, Nov 22, 2025 at 03:31:24PM +0100, Michal Meloun wrote: > > > This patch KASSERTs almost immediately when the system enters multi-user > > > mode while processing mmap() syscall: > > > > > > panic: vm_object_coalesce: obj 0xc73ddb28 next_pindex 0x13 next_size 0x5 > > > obj_size 0x176 > > > > Yes, the assert was mis-placed. Please try this variant. > > > > commit 2b1a1bcd2926bd89b8422c665b0aa411e29c883b > > Author: Konstantin Belousov > > Date: Sat Nov 22 16:02:50 2025 +0200 > > > > vm_object_coalesce(): fix logic to detect coalesce possibility, simplify > > > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > index 5b4517d2bf0c..9bb4e54edd96 100644 > > --- a/sys/vm/vm_object.c > > +++ b/sys/vm/vm_object.c > > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > next_size >>= PAGE_SHIFT; > > next_pindex = OFF_TO_IDX(prev_offset) + prev_size; > > - if (prev_object->ref_count > 1 && > > - prev_object->size != next_pindex && > > + if (prev_object->ref_count > 1 || > > + prev_object->size != next_pindex || > > (prev_object->flags & OBJ_ONEMAPPING) == 0) { > > VM_OBJECT_WUNLOCK(prev_object); > > return (FALSE); > > } > > + KASSERT(next_pindex + next_size > prev_object->size, > > + ("vm_object_coalesce: " > > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > > + (uintmax_t)prev_object->size)); > > + > > /* > > * Account for the charge. > > */ > > @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > * Remove any pages that may still be in the object from a previous > > * deallocation. > > */ > > - if (next_pindex < prev_object->size) { > > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > > - next_size, 0); > > -#if 0 > > - if (prev_object->cred != NULL) { > > - KASSERT(prev_object->charge >= > > - ptoa(prev_object->size - next_pindex), > > - ("object %p overcharged 1 %jx %jx", prev_object, > > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > > - prev_object->charge -= ptoa(prev_object->size - > > - next_pindex); > > - } > > -#endif > > - } > > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > > + next_size, 0); > > /* > > * Extend the object if necessary. > > */ > > - if (next_pindex + next_size > prev_object->size) > > - prev_object->size = next_pindex + next_size; > > + prev_object->size = next_pindex + next_size; > > VM_OBJECT_WUNLOCK(prev_object); > > return (TRUE); > > Unfortunately, that didn't help. I will try the vm_map.c patch again for > confirmation. Would you please gather the same ddebugging info, with this patch applied? From nobody Sat Nov 22 17:33:46 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 4dDK275dhGz6HW01 for ; Sat, 22 Nov 2025 17:33:51 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDK271VZhz3bLH; Sat, 22 Nov 2025 17:33:50 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5AMHXltq063770; Sun, 23 Nov 2025 02:33:47 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1763832827; bh=tNzNlRLv5gD0vD/iw34tkJQTlngLk4YBXDnMNn0hmx0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Be8Cc7ZYExIhw2NU+1UlO2q9j3vb41G0JNdUZ5C+BIpIlFTrSC2gASJfsqyp+JQwj xphS86n7+MnxJMq9A1UeXhz96DnF32OadOS9cR4zQqO1bu16Ql78dUJKJNCmDiYvMv 7on/v3xY6CDhZNj/97Us/kj8gfEUffvEYAVnMZBs= Date: Sun, 23 Nov 2025 02:33:46 +0900 From: Tomoaki AOKI To: Lexi Winter Cc: freebsd-current Subject: Re: changing from pkgbase to regularbase Message-Id: <20251123023346.185273222cc3c65515051ba8@dec.sakura.ne.jp> In-Reply-To: References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> <20251122215646.7e4f34e1955bca5dbf3261a0@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDK271VZhz3bLH On Sat, 22 Nov 2025 13:06:28 +0000 Lexi Winter wrote: > Tomoaki AOKI wrote in <20251122215646.7e4f34e1955bca5dbf3261a0@dec.sakura.ne.jp>: > > On Sat, 22 Nov 2025 11:39:56 +0000 > > Lexi Winter wrote: > > > Tomoaki AOKI wrote in <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp>: > > > > I don't think disallowing de-pkgbasifying is a good idea. > > > > > > we don't disallow depkgbasifying and there is no intention to do that. > > > > > Currently, IIUC, there's no pkgbasify and de-pkgbasify program > > in-tree. > > correct. there is no depkgbasify tool at all, as far as i know, since > pkg is missing functionality which is required to do that. > > > So preparing way to de-pkgbasify on nearly final step of the installer > > (just before "after-installation configurations" like adding user) would > > be helpful. > > this is planned for 16.0, since we will no longer ship distribution sets > and therefore need another solution to do non-pkgbase installs. Thanks! Glad to know it. > however i expect the UI to remain the same as it is now: you select > whether you want pkgbase or not, and if you choose not, bsdinstall > will silently do a pkgbase install then depkgbasify it. there's no > need to potentially confuse users by exposing what's happening > behind the scenes. I've re-read Chapter 2 of the Handbook. And things seems to be changed after I've actually used installer as installer (I'm using installer image to use Live CD mode for years, and the last time I've used the installer as installer, it was sysinstall(!). And often read Chapter 5 and later but not 4 and before. IIRC, at least on disc1 at the moment that had most of packages (of course, pre-pkg era) in it, sysinstall provided menu for selecting which packages the admin wants to be installed in post-installation configuration menu. I imagined the de-pkgbasifying menu to be shown just before it. But currently, post-Final Configuration (Chapter 2.8.7) but pre-"Complete" (allowing to choose from Reboot, Shutdown and Live CD) phase looks best fit. And I think the behavior you described looks reasonable here. Regards. -- Tomoaki AOKI From nobody Sat Nov 22 17:37: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 4dDK6T3cyZz6HWGs for ; Sat, 22 Nov 2025 17:37:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4dDK6S2T5zz3d1S for ; Sat, 22 Nov 2025 17:37:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aGPAfamx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763833048; bh=pYMd7st3O5walWCw48e0JtPHxPO9ZqczvKKoYfnK3Hc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=aGPAfamxkTNEjwYFIsqYZMVXlz5qDsVJzOivc2Vaz8AHGv/HJT8hQbYfmtOcYlAWdHPPSvWI6+ZenXn1Tph1E5TKmTi2XmKZAD0TtjXM9L90ml1NXSVxx2C1fIuDBsB/f4kiHQO7TnqOnDyOvESjZZFCwc7HHVXc/+fZ7Uha9W3hc/786/CQ86um2uBaWshPp+r+6PiZlwah/B7K0WbmMECLsM/Ji4O/bo9QwRr+CmFWhG/erVWRx+JfNiWZcvZRY2XOr4lxS5iVyyQdrETHw0f2ufxu7XbB4tz9wGYf90O071LKDgUIHhNHaQGMz1t8eRR+0bdY5WOugjHbHvx5Ug== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763833048; bh=l3Qhgb/ePfJw3q9BIcvuYG3W+WHG5OADNoR5Ms5hdYY=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HvMvDDzPxpBGC55RzMMW5PGsSZiu5MbLA39xiX/oZFopyBEiiGhtvZndti5wJVatZCILI2opnQsdzDbX497BBchYwfuL8y/IlTq9FQElCrftygYCbe0Gqv9z3UnzQmX7q13YstLOIGkFXAwmDZdNfpkmImLbqqK7DHymGg7QU8QHjUxD9bbNAdktKIbitxWB/v8EFZb5vNDA7GXfGtycwJngUk6jL0Y2y2iz9AM5aaG2KXXve6v4Sq1x0eyzjVKwwBJmJcwPkin9X68Km6pGmClbXPrUPLuvacuguundviHzeGxDd9Mp9umK/iDS02Fs+7Z0Fwti+tdpe5BkgU3mJw== X-YMail-OSG: pMAoZukVM1nQHXZ0aKSP5SyV6VOdglL.u5y2SDOUDpEyVQaTIgrsZTp1HR9kQIu TiVToC_7P33Jt_TJWaYeyiUb3VWj6nBiTLcxoeqywT3eeDNiiXyGSdeeHJgntBAx5hMS4J4EzUuJ lqV9XxzlF4N_YSB1sAC9cp.MyHRkJEZCEvB5iDNzJFKk3nijwExmuwTdQwK3kdqcCE6yN08Fku24 khKO_UtRd7N7eRLOYdTMWSKKjOLwdoPbwlUI4AwPGJOT6xotLSXrj3n4SbNhqhfUQTrqDkZkJ9Eo EmvpUspoSAxCH17kquLcZ.acMFJUMk4DIbNd7v9S9Y.Oh7UIhlBYs_2qNFMSQA0MOC_Bqx6TFW6g IYo_MGAmmULuA4c2wAcZwAVROQbemaf5j97Zv6B1HV8YlDDAvRnMl8Pos7JNkjPtsaCuc5ZGZpfT SQjN66wJqOAYlYOko8BLzN4MrhVgcHOBcgyHeO5w30_QpGk5FmhgaEVby8CIuSh8dKAwKsQ9ncoU 7jiES3IOXy06xwIwA24M7Db6sknYtVBX1l8DlyUWuOr65Tl6WTDlYQmTDoSHfCp3CXKP782hJsfr CUaIOkUOuV02.n.vk2XVKPhZUfZVpEnQMQmzjx6qRkHeRfGTxjHEY3BFjbHfnwOsJrNf84HzWwpZ dkFV0028fMkELl_0C0NCX6Gmrwk.VlfD5lxlbIrMJ0WS7CG437SrgzoiUj4H8kW84isT8TZuVyGE YNVYQggBvoyiZfvWVCRbqfmDpPkgPjHFlLC63UMmLsRmM0HZxuH4F5xl8TrZCqn.44QF7WmRd1hR 92QYCNB6O2OYtPpnylTDiza9i9qkdBf03fkb7TPBKWzMqOLC90uLR_FG59vcGPBks2u0TIpJRkd1 2DaPL8AGtv0RXv9TtCgFoOAw_Q_xepWbJZCRTMAilKgOr64X28iUdQVD.jORUPw7yil61kfO02G4 3.zECUfgcVH7VcJnUzv6mKw6mJdiEhR.LcrdLsxouAPmq7WpxEY_aaXCnT.3eSA2yflYbJty5tBP Q.DOFmaGRTbA.mOl0GS2i45iP3RBKyYfArQwGEX9WJf2tWlG2.tOE1q7p_n7ciPDHDIqmwxb6K0y lEz1BenN8Xfj8U5l35uiLg_0JODnaG2JkZgNCosQKhzDgV98_BZafpHfIUrmgU.wTpyNp1mzCM8k ka0qMddXndn6_KMMTHmED.ODPzaXNCW2NFf2nGE7icxQRfOCGrT1O.PYxKHcyC931nSLuT_RgA3O ONaSyDhRpWM5uezYluhJCKg_VivDINdhu3L7pevO.PZe_TC8qnRHFZLL0cuYCLYMdZv4n31H5q9u aOn7gLoEfyzvTHgjMKl9BNwNmvVC5XYsgtB9_uTeRfP50cV1P0mB_jons75Zt1MU_VRLXL8GQIRC K0VO_1_exdOHLCFyWPEELe5rCMZw3n69LmH80uFXNERuS3ABEW.G8G.H4sjufPDG2THu8eX0abK3 xi5TTqI8So18GdIYCbHLWaQp745pYBdvd71VRO.R8xHruCI3V.6EhldKaEgPGkYyFJErCO25lK8C xdGuqfYlXJ6zdIM_8dDIMT.NupvH_m5Z2cymVcCxQuPMF.lmbEHxIJRgXgBULNq5sz4s4x3ONYXP 0G..lTr3FjnFBU1ieNzRXSooVJVP2dPRgr_H8UjmoHJaDIFIfQoLP_8w40A1PnLRPTQ1wszFaqsO aRZ1EPIuZl4qB0Gpyg3SxoZkqPdzSCcX2nDpVbVFQqYy5ChVf065jdn3aV5Cn7EgYOA9vuhqgmMh u10im59ht5PImsbkq29PO2tVbUKKMjqFvV34UHm9QTaa2HNuuXxj2kAfqhqK55CEVhWIcIk1Tt.K OiUTxDJCBrzBrdSS8rn7f05Oq1NbhVGbFmmq9197RInEoLTzYN3weG4n31npfI3zSU_oLyFemWlJ RtlEWBa6kf0BzepQMzE2bzylnTwwBFt6frQpBG7eSectfeeQEg1l1C80wYOz9zjZsGiFrxaX7Whg 2XlL0e_uLosq04neddiYzJMCrhhSoooXUmMBSvya7k2dgkH4Wu3pTcuorc8rGM0gkkIqS5be6Mrh hXe5D.M8ngIi83PSWhDl.rCykXS48rmbckbvJO7zB2nCnFMCwoUaL.66MzJb555BAmKICxkICDEx Nj6V58M_pI2rGt561wvGdtSH1wK23c5vqiWwf5Wje94bp5TQRafSNBje.ooq1qEUUijYX9OHFErK 08Lb0BzeLrTX9uJV7mmacuVH4urTOG2qtWiCEwb5IOr1MuN4YauKrW65akiIeIXgCD083BLz_eik SNydclRfGsBVUHGeRz1rh5GOO X-Sonic-MF: X-Sonic-ID: 310f6f0e-efa7-4944-ab7e-72afffcf2318 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Nov 2025 17:37:28 +0000 Received: by hermes--production-gq1-fdb64d996-whpwx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3c9a76b6a49b0ec49a173a1940999360; Sat, 22 Nov 2025 17:37:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-Id: <7435C4D0-94AF-41FA-B9A0-2E5091F5A727@yahoo.com> Date: Sat, 22 Nov 2025 09:37:15 -0800 To: Michal Meloun , Konstantin Belousov , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <7435C4D0-94AF-41FA-B9A0-2E5091F5A727.ref@yahoo.com> X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_SHORT(0.27)[0.273]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from] X-Rspamd-Queue-Id: 4dDK6S2T5zz3d1S Michal Meloun wrote on Date: Sat, 22 Nov 2025 16:37:19 UTC : > On 22.11.2025 16:40, Konstantin Belousov wrote: > > On Sat, Nov 22, 2025 at 03:31:24PM +0100, Michal Meloun wrote: > >> This patch KASSERTs almost immediately when the system enters = multi-user > >> mode while processing mmap() syscall: > >> > >> panic: vm_object_coalesce: obj 0xc73ddb28 next_pindex 0x13 = next_size 0x5 > >> obj_size 0x176 > >=20 > > Yes, the assert was mis-placed. Please try this variant. > >=20 > > commit 2b1a1bcd2926bd89b8422c665b0aa411e29c883b > > Author: Konstantin Belousov > > Date: Sat Nov 22 16:02:50 2025 +0200 > >=20 > > vm_object_coalesce(): fix logic to detect coalesce possibility, = simplify > >=20 > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > index 5b4517d2bf0c..9bb4e54edd96 100644 > > --- a/sys/vm/vm_object.c > > +++ b/sys/vm/vm_object.c > > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, > > next_size >>=3D PAGE_SHIFT; > > next_pindex =3D OFF_TO_IDX(prev_offset) + prev_size; > >=20 > > - if (prev_object->ref_count > 1 && > > - prev_object->size !=3D next_pindex && > > + if (prev_object->ref_count > 1 || > > + prev_object->size !=3D next_pindex || > > (prev_object->flags & OBJ_ONEMAPPING) =3D=3D 0) { > > VM_OBJECT_WUNLOCK(prev_object); > > return (FALSE); > > } > >=20 > > + KASSERT(next_pindex + next_size > prev_object->size, > > + ("vm_object_coalesce: " > > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > > + (uintmax_t)prev_object->size)); > > + > > /* > > * Account for the charge. > > */ > > @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, > > * Remove any pages that may still be in the object from a previous > > * deallocation. > > */ > > - if (next_pindex < prev_object->size) { > > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > > - next_size, 0); > > -#if 0 > > - if (prev_object->cred !=3D NULL) { > > - KASSERT(prev_object->charge >=3D > > - ptoa(prev_object->size - next_pindex), > > - ("object %p overcharged 1 %jx %jx", prev_object, > > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > > - prev_object->charge -=3D ptoa(prev_object->size - > > - next_pindex); > > - } > > -#endif > > - } > > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > > + next_size, 0); > >=20 > > /* > > * Extend the object if necessary. > > */ > > - if (next_pindex + next_size > prev_object->size) > > - prev_object->size =3D next_pindex + next_size; > > + prev_object->size =3D next_pindex + next_size; > >=20 > > VM_OBJECT_WUNLOCK(prev_object); > > return (TRUE); >=20 > Unfortunately, that didn't help. I will try the vm_map.c patch again=20= > for confirmation. On amd64 I could not complete a boot: the KASSERT failed for equality instead of > : "next_pindex Oxf next_size 0x4 obj_size 0x19" QUOTE (from a prior message to the list): No serial console so a summary from a picture (expect typos): . . . ue0: link state changed to UP panic: vm_object_coalesce: obj Oxfffff800090a27c0 next_pindex Oxf = next_size 0x4 obj_size 0x19 . . . vm_object_coalesce vm_map_insert1 vm_map_find_locked pipespace_new pipe_paircreate kern_pipe sys_pipe2 amd64_syscall fast_syscall_common syscall END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Nov 22 18:22:39 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 4dDL6h5kpbz6HZRC for ; Sat, 22 Nov 2025 18:22:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDL6h2bDBz3lFS; Sat, 22 Nov 2025 18:22:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AMIMeE2017672; Sat, 22 Nov 2025 20:22:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AMIMeE2017672 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AMIMe3k017671; Sat, 22 Nov 2025 20:22:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 20:22:39 +0200 From: Konstantin Belousov To: Mark Millard Cc: Michal Meloun , FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <7435C4D0-94AF-41FA-B9A0-2E5091F5A727.ref@yahoo.com> <7435C4D0-94AF-41FA-B9A0-2E5091F5A727@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: <7435C4D0-94AF-41FA-B9A0-2E5091F5A727@yahoo.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDL6h2bDBz3lFS On Sat, Nov 22, 2025 at 09:37:15AM -0800, Mark Millard wrote: > Michal Meloun wrote on > Date: Sat, 22 Nov 2025 16:37:19 UTC : > > > On 22.11.2025 16:40, Konstantin Belousov wrote: > > > On Sat, Nov 22, 2025 at 03:31:24PM +0100, Michal Meloun wrote: > > >> This patch KASSERTs almost immediately when the system enters multi-user > > >> mode while processing mmap() syscall: > > >> > > >> panic: vm_object_coalesce: obj 0xc73ddb28 next_pindex 0x13 next_size 0x5 > > >> obj_size 0x176 > > > > > > Yes, the assert was mis-placed. Please try this variant. > > > > > > commit 2b1a1bcd2926bd89b8422c665b0aa411e29c883b > > > Author: Konstantin Belousov > > > Date: Sat Nov 22 16:02:50 2025 +0200 > > > > > > vm_object_coalesce(): fix logic to detect coalesce possibility, simplify > > > > > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > > index 5b4517d2bf0c..9bb4e54edd96 100644 > > > --- a/sys/vm/vm_object.c > > > +++ b/sys/vm/vm_object.c > > > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > > next_size >>= PAGE_SHIFT; > > > next_pindex = OFF_TO_IDX(prev_offset) + prev_size; > > > > > > - if (prev_object->ref_count > 1 && > > > - prev_object->size != next_pindex && > > > + if (prev_object->ref_count > 1 || > > > + prev_object->size != next_pindex || > > > (prev_object->flags & OBJ_ONEMAPPING) == 0) { > > > VM_OBJECT_WUNLOCK(prev_object); > > > return (FALSE); > > > } > > > > > > + KASSERT(next_pindex + next_size > prev_object->size, > > > + ("vm_object_coalesce: " > > > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > > > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > > > + (uintmax_t)prev_object->size)); > > > + > > > /* > > > * Account for the charge. > > > */ > > > @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > > * Remove any pages that may still be in the object from a previous > > > * deallocation. > > > */ > > > - if (next_pindex < prev_object->size) { > > > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > > > - next_size, 0); > > > -#if 0 > > > - if (prev_object->cred != NULL) { > > > - KASSERT(prev_object->charge >= > > > - ptoa(prev_object->size - next_pindex), > > > - ("object %p overcharged 1 %jx %jx", prev_object, > > > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > > > - prev_object->charge -= ptoa(prev_object->size - > > > - next_pindex); > > > - } > > > -#endif > > > - } > > > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > > > + next_size, 0); > > > > > > /* > > > * Extend the object if necessary. > > > */ > > > - if (next_pindex + next_size > prev_object->size) > > > - prev_object->size = next_pindex + next_size; > > > + prev_object->size = next_pindex + next_size; > > > > > > VM_OBJECT_WUNLOCK(prev_object); > > > return (TRUE); > > > > Unfortunately, that didn't help. I will try the vm_map.c patch again > > for confirmation. > > On amd64 I could not complete a boot: the KASSERT failed for equality > instead of > : "next_pindex Oxf next_size 0x4 obj_size 0x19" > > QUOTE (from a prior message to the list): > No serial console so a summary from a picture > (expect typos): > > . . . > ue0: link state changed to UP > panic: vm_object_coalesce: obj Oxfffff800090a27c0 next_pindex Oxf next_size 0x4 obj_size 0x19 Remove this assertion from your source. The right fix is to move it later, but it does not matter for the testing. From nobody Sat Nov 22 18:45:32 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 4dDLd52RKBz6HMtD for ; Sat, 22 Nov 2025 18:45:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDLd43XP1z3pCv; Sat, 22 Nov 2025 18:45:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AMIjW30018765; Sat, 22 Nov 2025 20:45:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AMIjW30018765 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AMIjWhg018764; Sat, 22 Nov 2025 20:45:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 20:45:32 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> 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: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDLd43XP1z3pCv On Sat, Nov 22, 2025 at 07:01:03PM +0100, Michal Meloun wrote: > > Would you please gather the same ddebugging info, with this patch applied? > Oups, sorry. > In meantime, next round with he vm_map patch finished successfully. It was still the case of coalescing previous entry and the mapping. It is weird, the patch ensures that there is no pages in the object backing the new region, and due to the ensured properties of the object, there should be no way to create pages under us. I am almost sure that the provided patch is correct, but it might be some additional cases that I miss. Please apply the following debugging patch, it includes the vm_object' part. Instead of allowing the corruption in userspace, kernel should panic now. Can you confirm that? diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 6b09552c5fee..76808b5ad7f1 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, (vm_size_t)(prev_entry->end - prev_entry->start), (vm_size_t)(end - prev_entry->end), cred != NULL && (protoeflags & MAP_ENTRY_NEEDS_COPY) == 0)) { + vm_object_t obj = prev_entry->object.vm_object; + if (obj != NULL) { + struct pctrie_iter pages; + vm_page_t p; + + vm_page_iter_init(&pages, obj); + p = vm_radix_iter_lookup_ge(&pages, + OFF_TO_IDX(prev_entry->offset + + prev_entry->end - prev_entry->start)); + if (p != NULL) { + KASSERT(p->pindex >= OFF_TO_IDX(prev_entry->offset + + prev_entry->end - prev_entry->start + + end - start), + ("FOUND page %p pindex %#jx " + "e %#jx %#jx %#jx %#jx", + p, p->pindex, (uintmax_t)prev_entry->offset, + (uintmax_t)prev_entry->end, + (uintmax_t)prev_entry->start, + (uintmax_t)(end - start))); + } + } /* * We were able to extend the object. Determine if we * can extend the previous map entry to include the diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 5b4517d2bf0c..9bb4e54edd96 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, next_size >>= PAGE_SHIFT; next_pindex = OFF_TO_IDX(prev_offset) + prev_size; - if (prev_object->ref_count > 1 && - prev_object->size != next_pindex && + if (prev_object->ref_count > 1 || + prev_object->size != next_pindex || (prev_object->flags & OBJ_ONEMAPPING) == 0) { VM_OBJECT_WUNLOCK(prev_object); return (FALSE); } + KASSERT(next_pindex + next_size > prev_object->size, + ("vm_object_coalesce: " + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, + (uintmax_t)prev_object->size)); + /* * Account for the charge. */ @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, * Remove any pages that may still be in the object from a previous * deallocation. */ - if (next_pindex < prev_object->size) { - vm_object_page_remove(prev_object, next_pindex, next_pindex + - next_size, 0); -#if 0 - if (prev_object->cred != NULL) { - KASSERT(prev_object->charge >= - ptoa(prev_object->size - next_pindex), - ("object %p overcharged 1 %jx %jx", prev_object, - (uintmax_t)next_pindex, (uintmax_t)next_size)); - prev_object->charge -= ptoa(prev_object->size - - next_pindex); - } -#endif - } + vm_object_page_remove(prev_object, next_pindex, next_pindex + + next_size, 0); /* * Extend the object if necessary. */ - if (next_pindex + next_size > prev_object->size) - prev_object->size = next_pindex + next_size; + prev_object->size = next_pindex + next_size; VM_OBJECT_WUNLOCK(prev_object); return (TRUE); From nobody Sat Nov 22 19:54:21 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 4dDN8J1TJhz6HT7r for ; Sat, 22 Nov 2025 19:54:24 +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 4dDN8J0nfRz40HZ; Sat, 22 Nov 2025 19:54:24 +0000 (UTC) (envelope-from mmel@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763841264; 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=vZeF4WJpwiVLdT+/7bQYLoKC6rT7xkVmFOxtRHjqgF0=; b=IULP3Ve/ZFAr42VY9h2issupxYBwXXK6G1R4r5EHDb5dWPDGo0qqIeod85CdUXYMtcgflK p09lldbnni+KtZcwejN6nJ/IKZCNDYXGECiq+vUaE+1MhbKNOGKSI8iUlkTpgDOiOMZ+Hg Pt0fM5RBeCLBayIpt/4yDoAHnJlcmKj4QlxolO+X9y9wt6DnD/4dBCA2UppHCJe+oma1NB fr98j4HG4yeHiuqXzb6BG0TuN6IOYQ5rQoqpn4eM3pcEUvjDei+nGAMvhUVhf/LIizOA3v 4E8YJpZoUxY95uGM1cXYXRojiZiIaPz8wlubFlyY6RKcn3RKaJ5hWrPMpTsteQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763841264; 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=vZeF4WJpwiVLdT+/7bQYLoKC6rT7xkVmFOxtRHjqgF0=; b=v00A+uggTmwBjwVjfLDSrlUQ1rNrGWEXtGoUWXJMqnezxj8GZyWZ3FkiY9Pw4H4JmzHTAm fuZAGOKdNchI2gxdt8O8V3cuVUOafC2x8MkuGcCz2KRsUwMc7ijyBrDMcLqnfIaZnbRbjT TeLdmOgQNeFOX09+H2L1hNyVmQayLuMPy3okpbyFqSVB+HClhtGZIU/NRZF+4ZMyraxZ6S Q982iXkybTHqprblNaHkMNfb2hlagwtX4lN7SmG7jiHl/mtSmQWuhaxy96wT0mRlTk67Vi ZQs5P68yQUIPpkiFYl3+kEWOh6vtQ5wfHKqa8T8w05URJLnPMCL1Qts/Gav5Yw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763841264; a=rsa-sha256; cv=none; b=Cqv1Ui+JV9uqm0DaFEfMMxYcqKe79UphTX48ox5RfiDlmewcG/mqCZGYYzSp/b/4XBSXz1 WSZ2iIktIDQLBsPlm2oY/wAilvaJS7AjOxUaCWoN1kvHqYmzsNIcvO0brOT9zCSqpQMm+5 fYnFplfRExA2q56m6HhHT5agLpdP2XXD5DVapJzWkosJz78kyumGrHHB7nsUIqzsDm58Mz 8Qt+3ylbv24L/L1lOFbiZMgYal23gA/XiBKIotHCI5qndaTCzf6t3NUcsgI2PxclS+/6dp IE4s+Hpm5SryLqJlGdxsTwVZWQbeMLQ7ShOiBGZbwVroAChNGDsBiP5UznD4Kg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (lety.radiolinkplus.cz [109.205.241.143]) (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 4dDN8H4lVKzvRM; Sat, 22 Nov 2025 19:54:23 +0000 (UTC) (envelope-from mmel@freebsd.org) Message-ID: <9a864c53-0033-46d1-ad07-6b528115789f@freebsd.org> Date: Sat, 22 Nov 2025 20:54:21 +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 From: Michal Meloun Reply-To: mmel@FreeBSD.org Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) To: Konstantin Belousov Cc: FreeBSD Current References: <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22.11.2025 19:45, Konstantin Belousov wrote: > On Sat, Nov 22, 2025 at 07:01:03PM +0100, Michal Meloun wrote: >>> Would you please gather the same ddebugging info, with this patch applied? >> Oups, sorry. >> In meantime, next round with he vm_map patch finished successfully. > > It was still the case of coalescing previous entry and the mapping. > > It is weird, the patch ensures that there is no pages in the object > backing the new region, and due to the ensured properties of the object, > there should be no way to create pages under us. > I am almost sure that the provided patch is correct, but it might be > some additional cases that I miss. > > Please apply the following debugging patch, it includes the vm_object' > part. Instead of allowing the corruption in userspace, kernel should > panic now. Can you confirm that? > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 6b09552c5fee..76808b5ad7f1 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > (vm_size_t)(prev_entry->end - prev_entry->start), > (vm_size_t)(end - prev_entry->end), cred != NULL && > (protoeflags & MAP_ENTRY_NEEDS_COPY) == 0)) { > + vm_object_t obj = prev_entry->object.vm_object; > + if (obj != NULL) { > + struct pctrie_iter pages; > + vm_page_t p; > + > + vm_page_iter_init(&pages, obj); > + p = vm_radix_iter_lookup_ge(&pages, > + OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start)); > + if (p != NULL) { > + KASSERT(p->pindex >= OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start + > + end - start), > + ("FOUND page %p pindex %#jx " > + "e %#jx %#jx %#jx %#jx", > + p, p->pindex, (uintmax_t)prev_entry->offset, > + (uintmax_t)prev_entry->end, > + (uintmax_t)prev_entry->start, > + (uintmax_t)(end - start))); > + } > + } > /* > * We were able to extend the object. Determine if we > * can extend the previous map entry to include the > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..9bb4e54edd96 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > next_size >>= PAGE_SHIFT; > next_pindex = OFF_TO_IDX(prev_offset) + prev_size; > > - if (prev_object->ref_count > 1 && > - prev_object->size != next_pindex && > + if (prev_object->ref_count > 1 || > + prev_object->size != next_pindex || > (prev_object->flags & OBJ_ONEMAPPING) == 0) { > VM_OBJECT_WUNLOCK(prev_object); > return (FALSE); > } > > + KASSERT(next_pindex + next_size > prev_object->size, > + ("vm_object_coalesce: " > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > + (uintmax_t)prev_object->size)); > + > /* > * Account for the charge. > */ > @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > * Remove any pages that may still be in the object from a previous > * deallocation. > */ > - if (next_pindex < prev_object->size) { > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > - next_size, 0); > -#if 0 > - if (prev_object->cred != NULL) { > - KASSERT(prev_object->charge >= > - ptoa(prev_object->size - next_pindex), > - ("object %p overcharged 1 %jx %jx", prev_object, > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > - prev_object->charge -= ptoa(prev_object->size - > - next_pindex); > - } > -#endif > - } > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > + next_size, 0); > > /* > * Extend the object if necessary. > */ > - if (next_pindex + next_size > prev_object->size) > - prev_object->size = next_pindex + next_size; > + prev_object->size = next_pindex + next_size; > > VM_OBJECT_WUNLOCK(prev_object); > return (TRUE); Unfortunately, KASSERT doesn't assert on failure. Don't hit me, please. :) Could this be related to the fact that the VMA has another region immediately after added page? __je_pages_map: addr: 0x0, ret: 0x34f6f000, size: 4096, alignment: 4096, prot: 0x00000003, flags: 0x0C001002 __je_pages_map: i: 0, p[i]: 0xFFFFF000, p: 0x34f6f000 ... _3440 0x34f4e000 0x34f6e000 rw- 0 3 13 0 ----- sw 3440 0x34f6e000 0x34f70000 rw- 1 1 1 0 ----- sw 3440 0x34f70000 0x34f82000 rw- 0 3 13 0 ----- sw ... From nobody Sat Nov 22 20:19:33 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 4dDNjZ4XmMz6HWfG for ; Sat, 22 Nov 2025 20:19:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDNjZ0jtBz44l0; Sat, 22 Nov 2025 20:19:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AMKJXsg024598; Sat, 22 Nov 2025 22:19:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AMKJXsg024598 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AMKJXck024597; Sat, 22 Nov 2025 22:19:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 22:19:33 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <07201c46-6fb4-4514-aa88-490830edb010@freebsd.org> <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> <9a864c53-0033-46d1-ad07-6b528115789f@freebsd.org> 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: <9a864c53-0033-46d1-ad07-6b528115789f@freebsd.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDNjZ0jtBz44l0 On Sat, Nov 22, 2025 at 08:54:21PM +0100, Michal Meloun wrote: > > > On 22.11.2025 19:45, Konstantin Belousov wrote: > > On Sat, Nov 22, 2025 at 07:01:03PM +0100, Michal Meloun wrote: > > > > Would you please gather the same ddebugging info, with this patch applied? > > > Oups, sorry. > > > In meantime, next round with he vm_map patch finished successfully. > > > > It was still the case of coalescing previous entry and the mapping. > > > > It is weird, the patch ensures that there is no pages in the object > > backing the new region, and due to the ensured properties of the object, > > there should be no way to create pages under us. > > I am almost sure that the provided patch is correct, but it might be > > some additional cases that I miss. > > > > Please apply the following debugging patch, it includes the vm_object' > > part. Instead of allowing the corruption in userspace, kernel should > > panic now. Can you confirm that? > > > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > > index 6b09552c5fee..76808b5ad7f1 100644 > > --- a/sys/vm/vm_map.c > > +++ b/sys/vm/vm_map.c > > @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > > (vm_size_t)(prev_entry->end - prev_entry->start), > > (vm_size_t)(end - prev_entry->end), cred != NULL && > > (protoeflags & MAP_ENTRY_NEEDS_COPY) == 0)) { > > + vm_object_t obj = prev_entry->object.vm_object; > > + if (obj != NULL) { > > + struct pctrie_iter pages; > > + vm_page_t p; > > + > > + vm_page_iter_init(&pages, obj); > > + p = vm_radix_iter_lookup_ge(&pages, > > + OFF_TO_IDX(prev_entry->offset + > > + prev_entry->end - prev_entry->start)); > > + if (p != NULL) { > > + KASSERT(p->pindex >= OFF_TO_IDX(prev_entry->offset + > > + prev_entry->end - prev_entry->start + > > + end - start), > > + ("FOUND page %p pindex %#jx " > > + "e %#jx %#jx %#jx %#jx", > > + p, p->pindex, (uintmax_t)prev_entry->offset, > > + (uintmax_t)prev_entry->end, > > + (uintmax_t)prev_entry->start, > > + (uintmax_t)(end - start))); > > + } > > + } > > /* > > * We were able to extend the object. Determine if we > > * can extend the previous map entry to include the > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > index 5b4517d2bf0c..9bb4e54edd96 100644 > > --- a/sys/vm/vm_object.c > > +++ b/sys/vm/vm_object.c > > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > next_size >>= PAGE_SHIFT; > > next_pindex = OFF_TO_IDX(prev_offset) + prev_size; > > - if (prev_object->ref_count > 1 && > > - prev_object->size != next_pindex && > > + if (prev_object->ref_count > 1 || > > + prev_object->size != next_pindex || > > (prev_object->flags & OBJ_ONEMAPPING) == 0) { > > VM_OBJECT_WUNLOCK(prev_object); > > return (FALSE); > > } > > + KASSERT(next_pindex + next_size > prev_object->size, > > + ("vm_object_coalesce: " > > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > > + (uintmax_t)prev_object->size)); > > + > > /* > > * Account for the charge. > > */ > > @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > > * Remove any pages that may still be in the object from a previous > > * deallocation. > > */ > > - if (next_pindex < prev_object->size) { > > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > > - next_size, 0); > > -#if 0 > > - if (prev_object->cred != NULL) { > > - KASSERT(prev_object->charge >= > > - ptoa(prev_object->size - next_pindex), > > - ("object %p overcharged 1 %jx %jx", prev_object, > > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > > - prev_object->charge -= ptoa(prev_object->size - > > - next_pindex); > > - } > > -#endif > > - } > > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > > + next_size, 0); > > /* > > * Extend the object if necessary. > > */ > > - if (next_pindex + next_size > prev_object->size) > > - prev_object->size = next_pindex + next_size; > > + prev_object->size = next_pindex + next_size; > > VM_OBJECT_WUNLOCK(prev_object); > > return (TRUE); > > Unfortunately, KASSERT doesn't assert on failure. Don't hit me, please. :) > > Could this be related to the fact that the VMA has another region > immediately after added page? > > __je_pages_map: addr: 0x0, ret: 0x34f6f000, size: 4096, alignment: 4096, > prot: 0x00000003, flags: 0x0C001002 > __je_pages_map: i: 0, p[i]: 0xFFFFF000, p: 0x34f6f000 > ... > _3440 0x34f4e000 0x34f6e000 rw- 0 3 13 0 ----- sw > 3440 0x34f6e000 0x34f70000 rw- 1 1 1 0 ----- sw > 3440 0x34f70000 0x34f82000 rw- 0 3 13 0 ----- sw > ... Please in addition to the patch, enable debug.vm_check_pg_zero. From nobody Sat Nov 22 20:20:28 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 4dDNkr6SVRz6HWPC for ; Sat, 22 Nov 2025 20:20:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4dDNkr1qkpz45Zf for ; Sat, 22 Nov 2025 20:20:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ejmK7bSL; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763842845; bh=dWe6FZ9rcqGtIDPaYr3QrbUeCPdwJ9D0DzyPhTagriU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ejmK7bSLCqxPXsibKzfc7vaA+NrsVJCUxy4vOpZd5Gt+sLrg6X9yMrcUT8la26rLNDoGmS1sabcOW8yqqYOXrb0C/GMgeMMwLdugTQ0BpkAQlwx7C14mBpf2F+gZrP97a81VKEnwe17kFBh93pdZe6XGYchXy7SOOcBu9pTXFCLoyKC/LnfHtKj4jRHVivlWtnIBUrmTcVPx+7B80qOyNAofUPx606JKnwm9ocao6Jj6rDZU96tBu55C6DoxThVqZb5N+Adsm0NmfMcner18Mk8Ud/cfiAELikKr/wyq+97JFTD0J3SZv9SojWbcNJkklfgrderyXIv1J4+sI2Ia9A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763842845; bh=wZNb5hn8f6+YGnRKQ4//zW977MdDibV0sSpXpN+4l8t=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=nCWP3K2SbB9Gw6QLeg7sok+OlNu/N+KuehRgh/+s/Xku9hPESNPJrjPCOxZosZoOCYnHfossu9hjayDitM8AQ4iF13geuPzunKX1yOD27pDA8Mvypr9y+xsHS6+zqdma69Uzy6i+V7tp0T3XVELAt24u8x3RsxH185wjzu2Rd3idteRi+kUUXpThCB5cHR12kpKxZUCp3CnmXnxHStQhvMJ+7f/RHN748IfdJNY7pzVWIgvvo09wfSxjt19VFvVgorVB21yIr50FyTOdaelfFWW9ioEYjx7W8KCvbWjE6gY+cMoX2jQ3Veb9TtdE+XPNFMqVHXNSEVgTvsq2OCoTvw== X-YMail-OSG: jhkWOK4VM1mSarp7hsGfYd5azmEfb1vg60K7Gd8KJuGoyNMROCRzuffI4DXJ1qC uh9iWeBH_HtNM2slwrwI1RP.IPkDKUzlxfzlHE0W76RF9g_eu1AJmCTeTKRyJ_Q7gGgVt1jjL.wo pN0FZCyAzEDXd4op15MPR9YJU5Buxky19bNHOJIIJ.OCJw6Uj5cqSF9UCl9iV.qvOxY1I0.gtHRn B474zA7AF5cb1BlcsKbkMobRUklxRigriacvieJuqYmzKIIVzTu4CI47CmBP5JvEMNMjgh.3xmR4 Dp.AqZnB_tlzSUXx.ufH.EMg5AdXoM4P3AyuJOH2DPJ2ePCefMTcPxllSefCGZb.Cd_Ec2YgvXWW SoJEobAeOcLojeupus33f.uOZmu4_31xDFjzl0hj4yK9wy8f0phRa1ulKGkXy6RM0ez.m35iOgS3 zb5bbjSYiwsSAOvGZHy5wmnoQ7Hcg5SLc9Dso5oOzJ_WAqCzJkzLPK1bsPBoTD_H59MBenbOylno z6SD0j3dP2r2cOErE9TrWungLtRY4RiZz8jC.9Ehlilr6OBOZ9VN6TlR2WjNjxMHFIJHismIB8Tc di4ZMKYRlHx5kO84mk8wHrb6r2KCALoS06yFwL6RzMVwaAPyCeDRjS4kPXTrqackFhEVZNIeEX3L ULt4nndjUGbvLVgNIsYl5kSouUjeZ5wOYvgkRwlXjh7C12bwdd2uwcWWxG9yuv2FCUmTzEHewffw tVQj1pWgPmqajY4ljPwWAhDjJ.4fuucOis4RCauXClewzo8cG3XV7KCUCrMfsZ6Awizp2ztsikGh h_tpG.HwMc3DuFxX.mcSLITW6qEfXK_yesvZhGx0RF9TqqHyjrgYiHjfokVbmJ6fVAOqy3E5IKoJ W1jlXsoGpvl4VMdSCGk5.WN1UA4ZpLgR3ujA8p4VcxmGSwZPBpK3XlWhfSKFpUd9Wu9c8yFgvFgr iDGRhVTYi2drIZbYEDQ_OdU0PsyiwiTiHJ6gnBuA6xMfz4xAxWFyp34ajaDg6jP_Oo_DOPA8JZrn 9l2.RV38.YWgq_D_EBcgSkJPx8WWrRD9vHZiEwQUPHYzvSqxlMCHPCm5tLtio0JJaAGxrv5UIR0W QJhpmszSS6ey.RAHGgmJef3o24nsAYSEaAKlRCExKyPONWG6klFsDw8fGsK6GP8C7fck5vAfNDS. kqJdTaQDp7NuE4c.p_c2iOEt9qEMu_DFXviHTDSEB5mFgURMfoC231EQu6Tf3LFgI5Ti.uqbdUsd wwldmZaKr.M3Y86xsS_HOg4uiEkpq_XF2lcfcjEonlEqc6gZvKj7LWjfSzu5eEXk8XGIFojjEM38 uJjoEUK0kM50MClayeBJEMYTKSHL4QHGz50PtnERkOgxilAV1BuB86UdSG51O9mm6gkKEL_ANaoN 0SaV4Kug2Rbdo5EewUo8Z6wSSTx1ZpH8AC8MxoGv6Qt4Xfe2maqKt_ZOu5ilDD58Yh38m80HMiDF l5btreeDqfM0y_NpquaAk70DfD8us35QEtyWaWqNdBWmr6Bh3vpPW1Wx9EgiuIdwy7BrBXA5CNUC l10cTPm9ek5SFMD8VAmTbKKZJo60NyBsh3tPvOyBf6wW528ZK8DLLn.YDkwpf8KQtSuKFoXUTkvG 6VfQOn3ZldRjWsDTUI.sX4.pAOov3DIvrN0h.eTfOxhlpk5N3Eu5Y8EByi5fLIOXTZuNW_uk2JOH _uuqee4FS_L_XE2pgID6sDWXsE1FPJqgRMJIQDdTQFo3phXgB4V.6cRsH45LLYhCotQeel262wRY 91leplGbS_4YBG6WHV2FGm9AhlCbcy6RWvCBZgGb9yGqLcQs8rZ08RK0A1g9a2pxwZlYTNnUEM1R Hiefo3XJnjunwOSNOYoV4dEUl597ajbn7i48UDojeckdyyK_yrMZGq95BF2_Hz5sT3WB2cVXGf_k GzYEhei4MaXiO4XkZ7o2FjnytyuKYICqS713.IRRGKhWuyMjNHNwf7kQ7whhdYfo19pyWNMOEmSK 6apF2Ko0xS865PxHu7FXa6AXaPRzim1MKeN9Vh1pcdslbqA.1A41UEWpo.vuHel35BsvflQMIxKi BBthsiaZib8XWBxAOPI.3RsJIDNqrX6dLmEuzxFZucJTPndFc6SComQgPGLbh9xSsmMm1dsi1WbJ BIvuaStia31h8GTppARFHmYSzjaN69GhBoZCWVoyCE7MsZ.UkG3pQKd1Mi1xEpkS3qGpcxt5Iv0c 6dek4xSsfc8W8jR4A9u3eo6LsDW6ThZea387lGOyUcl5._euFwG33gtJK5ntavG.dK49m4dFBeDE - X-Sonic-MF: X-Sonic-ID: adf0261a-dd1e-4185-bba8-848e81c9dca3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Nov 2025 20:20:45 +0000 Received: by hermes--production-gq1-fdb64d996-snhd5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 269559ad2821cb43eb78f5d99e485e6a; Sat, 22 Nov 2025 20:20:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) [i386 chroot still fails with vm_map.c and vm_object.c patches] Message-Id: Date: Sat, 22 Nov 2025 12:20:28 -0800 To: Konstantin Belousov , Michal Meloun , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from] X-Rspamd-Queue-Id: 4dDNkr1qkpz45Zf Konstantin Belousov wrote on Date: Sat, 22 Nov 2025 18:45:32 UTC : > On Sat, Nov 22, 2025 at 07:01:03PM +0100, Michal Meloun wrote: > > > Would you please gather the same ddebugging info, with this patch = applied? > > Oups, sorry. > > In meantime, next round with he vm_map patch finished successfully. >=20 > It was still the case of coalescing previous entry and the mapping. >=20 > It is weird, the patch ensures that there is no pages in the object > backing the new region, and due to the ensured properties of the = object, > there should be no way to create pages under us. > I am almost sure that the provided patch is correct, but it might be > some additional cases that I miss. >=20 > Please apply the following debugging patch, it includes the vm_object' > part. Instead of allowing the corruption in userspace, kernel should > panic now. Can you confirm that? >=20 > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 6b09552c5fee..76808b5ad7f1 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t = object, vm_ooffset_t offset, > (vm_size_t)(prev_entry->end - prev_entry->start), > (vm_size_t)(end - prev_entry->end), cred !=3D NULL && > (protoeflags & MAP_ENTRY_NEEDS_COPY) =3D=3D 0)) { > + vm_object_t obj =3D prev_entry->object.vm_object; > + if (obj !=3D NULL) { > + struct pctrie_iter pages; > + vm_page_t p; > + > + vm_page_iter_init(&pages, obj); > + p =3D vm_radix_iter_lookup_ge(&pages, > + OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start)); > + if (p !=3D NULL) { > + KASSERT(p->pindex >=3D = OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start = + > + end - start), > + ("FOUND page %p pindex %#jx " > + "e %#jx %#jx %#jx %#jx", > + p, p->pindex, = (uintmax_t)prev_entry->offset, > + (uintmax_t)prev_entry->end, > + (uintmax_t)prev_entry->start, > + (uintmax_t)(end - start))); > + } > + } > /* > * We were able to extend the object. Determine if we > * can extend the previous map entry to include the > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..9bb4e54edd96 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -2189,13 +2189,19 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, > next_size >>=3D PAGE_SHIFT; > next_pindex =3D OFF_TO_IDX(prev_offset) + prev_size; > =20 > - if (prev_object->ref_count > 1 && > - prev_object->size !=3D next_pindex && > + if (prev_object->ref_count > 1 || > + prev_object->size !=3D next_pindex || > (prev_object->flags & OBJ_ONEMAPPING) =3D=3D 0) { > VM_OBJECT_WUNLOCK(prev_object); > return (FALSE); > } > =20 > + KASSERT(next_pindex + next_size > prev_object->size, > + ("vm_object_coalesce: " > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > + (uintmax_t)prev_object->size)); > + > /* > * Account for the charge. > */ > @@ -2222,26 +2228,13 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, > * Remove any pages that may still be in the object from a = previous > * deallocation. > */ > - if (next_pindex < prev_object->size) { > - vm_object_page_remove(prev_object, next_pindex, = next_pindex + > - next_size, 0); > -#if 0 > - if (prev_object->cred !=3D NULL) { > - KASSERT(prev_object->charge >=3D > - ptoa(prev_object->size - next_pindex), > - ("object %p overcharged 1 %jx %jx", = prev_object, > - (uintmax_t)next_pindex, = (uintmax_t)next_size)); > - prev_object->charge -=3D ptoa(prev_object->size = - > - next_pindex); > - } > -#endif > - } > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > + next_size, 0); > =20 > /* > * Extend the object if necessary. > */ > - if (next_pindex + next_size > prev_object->size) > - prev_object->size =3D next_pindex + next_size; > + prev_object->size =3D next_pindex + next_size; > =20 > VM_OBJECT_WUNLOCK(prev_object); > return (TRUE); For the i386 chroot test context, it still fails like before: . . . Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/ExtractAPI/ExtractAPIConsume= r.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/ExtractAPI/Serialization/Sym= bolGraphSerializer.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/ExtractAPI/TypedefUnderlying= TypeResolver.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/AffectedRangeManager.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/BreakableToken.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/ContinuationIndenter.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/DefinitionBlockSepara= tor.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/Format.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/FormatToken.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/FormatTokenLexer.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/IntegerLiteralSeparat= orFixer.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/MacroCallReconstructo= r.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/MacroExpander.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/NamespaceEndCommentsF= ixer.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/ObjCPropertyAttribute= OrderFixer.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/QualifierAlignmentFix= er.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/SortJavaScriptImports= .pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/TokenAnalyzer.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/TokenAnnotator.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/UnwrappedLineFormatte= r.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/UnwrappedLineParser.p= ico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/UsingDeclarationsSort= er.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Format/WhitespaceManager.pic= o Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/ASTConsumers.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/ASTMerge.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/ASTUnit.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/ChainedDiagnosticCo= nsumer.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/ChainedIncludesSour= ce.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/CompilerInstance.pi= co Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/CompilerInvocation.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/CreateInvocationFro= mCommandLine.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/DependencyFile.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/DependencyGraph.pic= o Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/DiagnosticRenderer.= pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/FrontendAction.pico= Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/FrontendActions.pic= o Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/FrontendOptions.pic= o : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Frontend/HeaderIncludeGen.pi= co Abort trap (core dumped) *** [ExtractAPI/ExtractAPIConsumer.pico] Error code 134 . . . For reference (from the amd64 boot context): # strings /boot/kernel.jemallocfailure/kernel | grep 'FOUND page %p = pindex %#jx' FOUND page %p pindex %#jx e %#jx %#jx %#jx %#jx # uname -apKU FreeBSD 7950X3D-UFS 16.0-CURRENT FreeBSD 16.0-CURRENT #3: Sat Nov 22 = 11:42:13 PST 2025 = root@7950X3D-UFS:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 = 1600004 1600004 The backtrace looks like: (lldb) bt * thread #1, name =3D 'c++', stop reason =3D signal SIGABRT * frame #0: 0x24bd378b libsys.so.7`__sys_thr_kill at thr_kill.S:4 frame #1: 0x2ab2231b libc.so.7`__raise(s=3D6) at raise.c:48:10 frame #2: 0x2abcc73b libc.so.7`abort at abort.c:61:8 frame #3: 0x2ac10440 = libc.so.7`ehooks_debug_zero_check(addr=3D, = size=3D) at ehooks.h:0 frame #4: 0x2ac0ccfa libc.so.7`__je_extent_alloc_wrapper [inlined] = ehooks_alloc(tsdn=3D, ehooks=3D, = new_addr=3D, size=3D, alignment=3D,= zero=3D0xffff7c7b, commit=3D) at ehooks.h:208:3 frame #5: 0x2ac0cc5a = libc.so.7`__je_extent_alloc_wrapper(tsdn=3D0x2adf90a0, pac=3D0x2b0015e4, = ehooks=3D0x2b000080, new_addr=3D0x00000000, size=3D20480, = alignment=3D4096, zero=3Dtrue, commit=3D0xffff7ce3, = growing_retained=3D) at jemalloc_extent.c:1003:15 frame #6: 0x2ac0c58e = libc.so.7`__je_ecache_alloc_grow(tsdn=3D0x2adf90a0, pac=3D0x2b0015e4, = ehooks=3D0x2b000080, ecache=3D0x2b0036d0, expand_edata=3D0x00000000, = size=3D20480, alignment=3D4096, zero=3D, = guarded=3D) at jemalloc_extent.c:126:11 frame #7: 0x2ac3c73f libc.so.7`pac_alloc_impl [inlined] = pac_alloc_real(tsdn=3D, pac=3D, = ehooks=3D, size=3D, alignment=3D4096, = zero=3D, guarded=3D) at jemalloc_pac.c:124:11 frame #8: 0x2ac3c696 libc.so.7`pac_alloc_impl(tsdn=3D0x2adf90a0, = self=3D0x2b0015e4, size=3D20480, alignment=3D4096, zero=3D, = guarded=3D, frequent_reuse=3D, = deferred_work_generated=3D) at jemalloc_pac.c:178:11 frame #9: 0x2ac3afe0 libc.so.7`__je_pa_alloc [inlined] = pai_alloc(tsdn=3D, self=3D, = size=3D, alignment=3D, zero=3D, = guarded=3D, frequent_reuse=3D, = deferred_work_generated=3D) at pai.h:43:9 frame #10: 0x2ac3afc9 libc.so.7`__je_pa_alloc(tsdn=3D0x2adf90a0, = shard=3D0x2b0015d8, size=3D20480, alignment=3D4096, slab=3D, = szind=3D25, zero=3D, guarded=3D, = deferred_work_generated=3D0xffff7dc7) at jemalloc_pa.c:139:11 frame #11: 0x2abec82b libc.so.7`arena_slab_alloc(tsdn=3D,= arena=3D, binind=3D25, binshard=3D0, bin_info=3D0x2ac71658) = at jemalloc_arena.c:839:18 frame #12: 0x2abebdaa = libc.so.7`__je_arena_cache_bin_fill_small(tsdn=3D0x2adf90a0, = arena=3D0x2b000500, cache_bin=3D0x2adf94e8, cache_bin_info=3D0x2b0004b2, = binind=3D25, nfill=3D10) at jemalloc_arena.c:1034:16 frame #13: 0x2ac2b737 = libc.so.7`__je_tcache_alloc_small_hard(tsdn=3D0x2adf90a0, = arena=3D0x2b000500, tcache=3D0x2adf92f0, cache_bin=3D0x2adf94e8, = binind=3D25, tcache_success=3D0xffff7e8b) at jemalloc_tcache.c:238:2 frame #14: 0x2abed8e3 libc.so.7`arena_malloc [inlined] = tcache_alloc_small(tsd=3D, arena=3D0x2b000500, = tcache=3D, size=3D, binind=3D, = zero=3D, slow_path=3Dtrue) at tcache_inlines.h:68:9 frame #15: 0x2abed83e libc.so.7`arena_malloc(tsdn=3D, = arena=3D, size=3D2560, ind=3D25, zero=3D, = tcache=3D0x2adf92f0, slow_path=3Dtrue) at arena_inlines_b.h:151:11 frame #16: 0x2abed610 libc.so.7`__je_arena_palloc(tsdn=3D0x2adf90a0, = arena=3D0x00000000, usize=3D2560, alignment=3D4, zero=3D, = tcache=3D0x2adf92f0) at jemalloc_arena.c:1224:9 frame #17: 0x2abe7838 libc.so.7`ipalloct [inlined] = ipallocztm(tsdn=3D, usize=3D2560, alignment=3D4, = zero=3D, tcache=3D0x2adf92f0, is_internal=3Dfalse, = arena=3D0x00000000) at jemalloc_internal_inlines_c.h:80:8 frame #18: 0x2abe7705 libc.so.7`ipalloct(tsdn=3D, = usize=3D2560, alignment=3D4, zero=3D, tcache=3D0x2adf92f0, = arena=3D0x00000000) at jemalloc_internal_inlines_c.h:91:9 frame #19: 0x2abe754c libc.so.7`imalloc_body [inlined] = imalloc_no_sample(sopts=3D0xffff7f9c, dopts=3D0xffff7f7c, = tsd=3D0x2adf90a0, size=3D2304, usize=3D2560, ind=3D0) at = jemalloc_jemalloc.c:2398:10 frame #20: 0x2abe753f libc.so.7`imalloc_body(sopts=3D, = dopts=3D, tsd=3D0x2adf90a0) at jemalloc_jemalloc.c:2577:16 frame #21: 0x2abdae88 libc.so.7`imalloc(sopts=3D, = dopts=3D) at tsd.h:0:2 frame #22: 0x2abdb3ef libc.so.7`__aligned_alloc(alignment=3D4, = size=3D2304) at jemalloc_jemalloc.c:2821:2 frame #23: 0x2aa69777 libc++.so.1`operator new(unsigned int, = std::align_val_t) [inlined] = std::__1::__libcpp_aligned_alloc[abi:se190107](__alignment=3D4, = __size=3D) at aligned_alloc.h:43:10 frame #24: 0x2aa69768 libc++.so.1`operator new(unsigned int, = std::align_val_t) [inlined] = operator_new_aligned_impl(size=3D, alignment=3D4) at = new.cpp:129:15 frame #25: 0x2aa69748 libc++.so.1`operator new(size=3D2304, = alignment=3D4) at new.cpp:141:13 frame #26: 0x28a7905b = libprivatellvm.so.19`llvm::allocate_buffer(unsigned int, unsigned int) = at MemAlloc.cpp:16:10 frame #27: 0x26fa313e libprivatellvm.so.19`::grow() [inlined] = allocateBuckets at DenseMap.h:915:9 frame #28: 0x26fa312d libprivatellvm.so.19`::grow() at = DenseMap.h:849:5 frame #29: 0x26fa30a5 = libprivatellvm.so.19`::InsertIntoBucketImpl >() [inlined] grow at DenseMap.h:580:36 frame #30: 0x26fa309e = libprivatellvm.so.19`::InsertIntoBucketImpl >() at DenseMap.h:0 frame #31: 0x26fa2f51 libprivatellvm.so.19`::FindAndConstruct() = [inlined] InsertIntoBucket > = at DenseMap.h:590:17 frame #32: 0x26fa2f48 libprivatellvm.so.19`::FindAndConstruct() at = DenseMap.h:381:13 frame #33: 0x26f9f3fe libprivatellvm.so.19`::initializeRPOT() = [inlined] operator[] at DenseMap.h:385:12 frame #34: 0x26f9f3f0 libprivatellvm.so.19`::initializeRPOT() at = BlockFrequencyInfoImpl.h:1173:5 frame #35: 0x26f99bbd libprivatellvm.so.19`::calculate() at = BlockFrequencyInfoImpl.h:1119:3 frame #36: 0x26f992a0 libprivatellvm.so.19`::calculate() at = BlockFrequencyInfo.cpp:189:8 frame #37: 0x26f9bc3a = libprivatellvm.so.19`llvm::BlockFrequencyAnalysis::run(llvm::Function&, = llvm::AnalysisManager&) at BlockFrequencyInfo.cpp:338:7 frame #38: 0x2880e51b libprivatellvm.so.19`::run() at = PassManagerInternal.h:320:14 frame #39: 0x283b7e8b libprivatellvm.so.19`::getResultImpl() at = PassManagerImpl.h:156:35 frame #40: 0x26f9c0a6 = libprivatellvm.so.19`::getResult() at = PassManager.h:409:9 frame #41: 0x29b202aa libprivatellvm.so.19`::run() at = Inliner.cpp:385:16 frame #42: 0x2882dbad = libprivatellvm.so.19`llvm::detail::PassModel, llvm::LazyCallGraph&, = llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, = llvm::AnalysisManager&, = llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) at = PassManagerInternal.h:90:17 frame #43: 0x26fd7933 libprivatellvm.so.19`::run() at = CGSCCPassManager.cpp:87:38 frame #44: 0x2881959d = libprivatellvm.so.19`llvm::detail::PassModel, = llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>, = llvm::AnalysisManager, = llvm::LazyCallGraph&, = llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, = llvm::AnalysisManager&, = llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) at = PassManagerInternal.h:90:17 frame #45: 0x26fda8e4 libprivatellvm.so.19`::run() at = CGSCCPassManager.cpp:413:38 frame #46: 0x28849d1d = libprivatellvm.so.19`llvm::detail::PassModel, = llvm::LazyCallGraph&, = llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, = llvm::AnalysisManager&, = llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) at = PassManagerInternal.h:90:17 frame #47: 0x26fd901f libprivatellvm.so.19`::run() at = CGSCCPassManager.cpp:274:44 frame #48: 0x288198a7 = libprivatellvm.so.19`llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) at PassManagerInternal.h:90:17 frame #49: 0x283b43bd libprivatellvm.so.19`::run() at = PassManagerImpl.h:81:38 frame #50: 0x29b224ef libprivatellvm.so.19`::run() at = Inliner.cpp:631:7 frame #51: 0x288235a7 = libprivatellvm.so.19`llvm::detail::PassModel>::run(llvm::Module&, = llvm::AnalysisManager&) at PassManagerInternal.h:90:17 frame #52: 0x283b43bd libprivatellvm.so.19`::run() at = PassManagerImpl.h:81:38 frame #53: 0x228e956a = libprivateclang.so.19`::RunOptimizationPipeline() at = BackendUtil.cpp:1114:9 frame #54: 0x228e000c libprivateclang.so.19`::EmitBackendOutput() = [inlined] EmitAssembly at BackendUtil.cpp:1179:3 frame #55: 0x228df8a5 libprivateclang.so.19`::EmitBackendOutput() at = BackendUtil.cpp:1341:13 frame #56: 0x22d84b4d = libprivateclang.so.19`::HandleTranslationUnit() at = CodeGenAction.cpp:354:3 frame #57: 0x234f63bd libprivateclang.so.19`::ParseAST() at = ParseAST.cpp:184:13 frame #58: 0x2335bdef libprivateclang.so.19`::ExecuteAction() at = FrontendAction.cpp:1192:3 frame #59: 0x22d8ad1d libprivateclang.so.19`::ExecuteAction() at = CodeGenAction.cpp:1144:30 frame #60: 0x2335b650 libprivateclang.so.19`::Execute() at = FrontendAction.cpp:1078:8 frame #61: 0x232bc3ac libprivateclang.so.19`::ExecuteAction() at = CompilerInstance.cpp:1061:33 frame #62: 0x233f3b7c = libprivateclang.so.19`::ExecuteCompilerInvocation() at = ExecuteCompilerInvocation.cpp:280:25 frame #63: 0x0040df8f c++`::cc1_main() at cc1_main.cpp:284:15 frame #64: 0x0041c927 c++`::ExecuteCC1Tool() at driver.cpp:215:12 frame #65: 0x22f460a6 libprivateclang.so.19`::callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>() = [inlined] operator() at STLFunctionalExtras.h:68:12 frame #66: 0x22f46097 libprivateclang.so.19`::callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>() = [inlined] operator() at Job.cpp:440:34 frame #67: 0x22f46094 libprivateclang.so.19`::callback_fn<(lambda at = /usr/src/contrib/llvm-project/clang/lib/Driver/Job.cpp:440:22)>() at = STLFunctionalExtras.h:45:12 frame #68: 0x28a3f834 libprivatellvm.so.19`::RunSafely() [inlined] = operator() at STLFunctionalExtras.h:68:12 frame #69: 0x28a3f82f libprivatellvm.so.19`::RunSafely() at = CrashRecoveryContext.cpp:426:3 frame #70: 0x22f456d4 libprivateclang.so.19`::Execute() at = Job.cpp:440:12 frame #71: 0x22f00688 libprivateclang.so.19`::ExecuteCommand() at = Compilation.cpp:199:15 frame #72: 0x22f0097e libprivateclang.so.19`::ExecuteJobs() at = Compilation.cpp:253:19 frame #73: 0x22f21e9c libprivateclang.so.19`::ExecuteCompilation() = at Driver.cpp:1943:5 frame #74: 0x0041bfdd c++`::clang_main() at driver.cpp:391:21 frame #75: 0x0041a387 c++`main at clang-driver.cpp:17:10 frame #76: 0x2aaf8820 libc.so.7`__libc_start1(argc=3D71, = argv=3D0xffffc28c, env=3D0xffffc3ac, cleanup=3D(ld-elf.so.1`rtld_nop_exit = at rtld.c:3602), mainX=3D(c++`main at clang-driver.cpp:15)) at = libc_start1.c:180:7 frame #77: 0x0040c438 c++`_start at crt1_s.S:84 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Nov 22 20:41:27 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 4dDPBr5gFvz6HYR0 for ; Sat, 22 Nov 2025 20:41:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDPBr0lPtz480m; Sat, 22 Nov 2025 20:41:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AMKfSKr025702; Sat, 22 Nov 2025 22:41:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AMKfSKr025702 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AMKfSLn025701; Sat, 22 Nov 2025 22:41:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2025 22:41:27 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> <9a864c53-0033-46d1-ad07-6b528115789f@freebsd.org> 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: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.32 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; NEURAL_HAM_SHORT(-0.97)[-0.970]; NEURAL_SPAM_LONG(0.64)[0.637]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_DN_ALL(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4dDPBr0lPtz480m On Sat, Nov 22, 2025 at 10:19:38PM +0200, Konstantin Belousov wrote: > Please in addition to the patch, enable debug.vm_check_pg_zero. And use the following patch (one more hunk for vm_object_page_remove()): diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 6b09552c5fee..76808b5ad7f1 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, (vm_size_t)(prev_entry->end - prev_entry->start), (vm_size_t)(end - prev_entry->end), cred != NULL && (protoeflags & MAP_ENTRY_NEEDS_COPY) == 0)) { + vm_object_t obj = prev_entry->object.vm_object; + if (obj != NULL) { + struct pctrie_iter pages; + vm_page_t p; + + vm_page_iter_init(&pages, obj); + p = vm_radix_iter_lookup_ge(&pages, + OFF_TO_IDX(prev_entry->offset + + prev_entry->end - prev_entry->start)); + if (p != NULL) { + KASSERT(p->pindex >= OFF_TO_IDX(prev_entry->offset + + prev_entry->end - prev_entry->start + + end - start), + ("FOUND page %p pindex %#jx " + "e %#jx %#jx %#jx %#jx", + p, p->pindex, (uintmax_t)prev_entry->offset, + (uintmax_t)prev_entry->end, + (uintmax_t)prev_entry->start, + (uintmax_t)(end - start))); + } + } /* * We were able to extend the object. Determine if we * can extend the previous map entry to include the diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 5b4517d2bf0c..e87047f9a380 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -1988,7 +1988,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t start, vm_pindex_t end, (options & (OBJPR_CLEANONLY | OBJPR_NOTMAPPED)) == OBJPR_NOTMAPPED, ("vm_object_page_remove: illegal options for object %p", object)); if (object->resident_page_count == 0) - return; + goto remove_pager; vm_object_pip_add(object, 1); vm_page_iter_limit_init(&pages, object, end); again: @@ -2061,6 +2061,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t start, vm_pindex_t end, } vm_object_pip_wakeup(object); +remove_pager: vm_pager_freespace(object, start, (end == 0 ? object->size : end) - start); } @@ -2189,13 +2190,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, next_size >>= PAGE_SHIFT; next_pindex = OFF_TO_IDX(prev_offset) + prev_size; - if (prev_object->ref_count > 1 && - prev_object->size != next_pindex && + if (prev_object->ref_count > 1 || + prev_object->size != next_pindex || (prev_object->flags & OBJ_ONEMAPPING) == 0) { VM_OBJECT_WUNLOCK(prev_object); return (FALSE); } + KASSERT(next_pindex + next_size > prev_object->size, + ("vm_object_coalesce: " + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, + (uintmax_t)prev_object->size)); + /* * Account for the charge. */ @@ -2222,26 +2229,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, * Remove any pages that may still be in the object from a previous * deallocation. */ - if (next_pindex < prev_object->size) { - vm_object_page_remove(prev_object, next_pindex, next_pindex + - next_size, 0); -#if 0 - if (prev_object->cred != NULL) { - KASSERT(prev_object->charge >= - ptoa(prev_object->size - next_pindex), - ("object %p overcharged 1 %jx %jx", prev_object, - (uintmax_t)next_pindex, (uintmax_t)next_size)); - prev_object->charge -= ptoa(prev_object->size - - next_pindex); - } -#endif - } + vm_object_page_remove(prev_object, next_pindex, next_pindex + + next_size, 0); /* * Extend the object if necessary. */ - if (next_pindex + next_size > prev_object->size) - prev_object->size = next_pindex + next_size; + prev_object->size = next_pindex + next_size; VM_OBJECT_WUNLOCK(prev_object); return (TRUE); From nobody Sat Nov 22 20:48:32 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 4dDPM81BKMz6HYpj for ; Sat, 22 Nov 2025 20:48:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4dDPM61gwGz4Bnx for ; Sat, 22 Nov 2025 20:48:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LTwjByq2; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763844526; bh=Y6f+eDzghOzwTx6pG0cf/vxBs2umE+qc/0LJmItcO5Q=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=LTwjByq281GLomusob+Nz5JM6lFMKCwDZoPYOG/Wjb7AgrGAf01yWhFczLUhgA8XNZROJ+oeoWBdyUOBBqHDf3ZE20XYBqIjdmEujWwckxJIxtATQA96IlpTNFn+7MQ1lm/cZLaJy2NxkeG5ZcOT8TIxRuJCQtxGRR0OekeagpHz6gL3ndmublntZ5DD0HOsxCdWX0nqtIQM9Xhr6870eWnzdUrUdIlZ/ULma4qqfwRgQcf+P9Yf5PmNT33SYv9or5y8JB8qD16rT2aCqmmjyIZL0eqygM7o/jr+xKWoGq5npACQA9Ut2a68pkRY7ii7QRKjk3NeIyxZlAaKgz7BjA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763844526; bh=zoT8A8Yn0LozEfg2IBU+OSEl5EUH1I3fydVVMRjwQ3b=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ENM0YpQmCRTZWa4ozxACtXqWHNehgaC5jEOIjkBq48C4UwSJve6JQYBKyJW4fik3NiX33PSdFDPUq78JGB83h9KLXE81ZXk8XWSrPlfyQ8/Q4IZvDc0yMemMW2Ph0j+EwCy7PADOqxXNmWDb/kM7b5jlBI5fY4OSl03gPqlyVGlaQtV1Tnn4mglcKWErb+thcKt/lHGOQ/+rW9xPwcAsY2axp5bJxu7XvkT6396sBYDi6/NmdPmfnGmWNZczrw9J74yB3069rK+8cWwWsjHyUc7ch0LHVoVjYkr2rkyIfhla0O+0UqGFIkCWYpAa46W7W8IWWY/L7Xc5wAwtWy+hYQ== X-YMail-OSG: 95j43kIVM1mKjkaVbdT8uJj4mjI5fnWvGNzC.utrSXqTXwA7GaSocB0irwkF6gE vcWGnpeY2zHjb1Xu5E4ikHesrYII.Sq7yzdojC2gTiPC1XNVchUYRueDYd0y7ua6Twvsnlvbndzl 4UYs8iHu6h9ZLZcW7UJRzZ6wqk_WdMi3NQnOY0JZTBK6NZ8RRyqX672HZJiku4NZKGOCYiWDv2aI Rici28ybtc_pJhU8BtWOFlVOz56B40nJSdxCJ8rXDlzKrXpQimZxwgR0kSONQ59Y8X9cxmPfnRxE YXdxRloN_ccX_tNiUNvYsWp2VlL9_AVbx1YYzlB2yeyAXBSjC.rd5quyE4Fz8I3pyP0lKV2Y.EqT Ukqd1Y.bLI1ihHMDBMdzGcelF38YPTa4OT6LaYNTEO1TR8LYs780ZcKAdXq5MhIKwCkkcDSiq.2F WgeN3Ck8KlN2HIf.o5DOJDsiC.9Cw4x2O.7f67RkynoXSrOcyP4Izh6hwVV75FgDfx_baN11wwzo gVxAcm6ROZYOS4TH8r6mB.y97ljZm22gG7B2TLtE8xWFoW3GnuT107rgrGvOzCxsMLl4RGNDJakt ZkOub6DwFX5LB.TqppUQGVkKQAWtZxTYH5gb0CkBVhULdPXZgfDVTyOZzC6PfykgIDaolHmwJY4H Xen1dyLuqGQnPQq8NlCG2s.vRmxWYaSm2zUev6XBNsW.b_svxAR.V6Y3u1fg1wj6nzmajqcLxyUB efm46aC4zAlZ9uIfukWI8fq0Zzs_JN9R6JS8KADS0fWmk1wMugIV2Dil9YDEoPc9jnKhI6ISqdor giFLgdap2wwT7vXMf3lw3dVf6ETqmIUnkwtYcp.xZTP_3JjnKeAByrOik2EVVzSbQ6zvRZh1J2P_ UymdXa9hxrlDTWezyuFsFY83a0kK8LZbxXqRZZVZ6ux_4y.gMnDmJomK3csWMj8YFmexL1A5ctS4 ccRA7a9gNuxch.V7tEf9yYZq31MiQ0M2LBG1U.TZ_SbLEvjRJcn9VzF_E7broKtW8l0jed4vSFTe ..L_.TiGadCikY4dASAMpsX8zOvMivbsIV.ZHx_he28Vwy5F9.DCwAeOADpuxZ7ZYcDSZdpoCSIw q7SdkEhEGplPcViGYyw0zYUFspLYyplRMzY9im0Q3Oua5GG2v1EngvlCZ9gK1QLnGZG6mv715Cy. hMTD9_hLiPxO_r0M0sd88B1_h.8tAEXA9Ua03AmyvqwghHBDMffKEji34q.HKsL99aJ44DVTTWmX 5d8SGvRXGQ3GAL_HmywJXIXfWHCRGsFAAqlc4WDs2O.uvK9rhcQjK5Cqq4TAsWhd2OEf7lUsxw1I l.2bi0JisztHBzXmNMYeEtcyrdvr5v0VaVP3GD6.QHPq.hvs6Bfe5AVtNeP5o1XJqR1fqsljqbdF a_VJkbo3f5eZ8IeKri2YjltXRRrV9g87v8t1tc2Ip9.mTQBVojkGItoFhjk4SxA.gbLu5rxGex4_ .lqNd.3gUeoQ_8Xouyc7Zz4M6NcX8ZNdeT_eiqLbIO9MzPhNhBA40uxhypce16cl2rSjyVvTTx0I ICtlu9cwcb4roohco9OQI3uflb6dmrvu3NwMFX.6teTn5ONKKCZ.ZkRfJ6O7c9xHvM7qc3qn6WYt zUE73jJBB1VgSKkHuuneGhTjuFfsCj.Y4MGqJVxEok61QL91Nn.OMMaBjxcggsvJWeoo46ZpVL6X r3wWyauDc0UAQBebCDETRi8y4oh3DpCPCK7mEkTp.pynz2d0qKx6RCb8Qp3E0pK.7My8XQZ14k7L twlxcNMjgzsFKU5vlJocJU1WmUKe1J2G9xnU.oIQX7.wk3M2Qf2tPsqDxlPVVWmrDwTZiTMwVNmh LAsvg.iza3SNSk9eTl2HNDydGfG3WpjnLGs3q2umfXIfJwKyQuySK7TANCWvW_fI0bckQDehkHDT .Tq3TModrw1rKWHSa60mMQ2Dt1esqpCDDaGv4sajUcXs1jx9cFf4JBASwuPzF4MftjKWdOoVyDYQ HLMrF1wb9klMFCgsgXOhKjwAqWSO3H5hghLlj2_dSnG0YivB.ErUzY7gFZVKwupDLkgTTPhOL8vc DoPamG7jzvThRsq0Uo1bU3lLEI5_Vkq8XH83mVGFA88nWnuxVsI81c7KgBm8JNsAEz0HC5rcRIFg NRnJYejIrI481nNp6SU1_GEcn91IoV1stRTqghZY.Ms.yK8aXqyIWR0igwM5g7sp4o4twCbuEHNj 2SHohHYvsxX_DdqPAYXIH_7.Hjg0vHcALHBOX1nTQuQmDib7hhnlrohV0BlD7LDK.kbWSJyxg5T1 F24g- X-Sonic-MF: X-Sonic-ID: a700d4c5-0415-4658-a5c2-a80523d6cd59 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Nov 2025 20:48:46 +0000 Received: by hermes--production-gq1-fdb64d996-dt44t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7fe2419a5564737cd2fc552f3ef7beca; Sat, 22 Nov 2025 20:48:42 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) [debug.vm_check_pg_zero=1 silent] Message-Id: <75CEABED-3CCB-4DB9-AC82-5980696C2A06@yahoo.com> Date: Sat, 22 Nov 2025 12:48:32 -0800 To: Konstantin Belousov , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <75CEABED-3CCB-4DB9-AC82-5980696C2A06.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from] X-Rspamd-Queue-Id: 4dDPM61gwGz4Bnx Konstantin Belousov wrote on Date: Sat, 22 Nov 2025 20:19:33 UTC : > On Sat, Nov 22, 2025 at 08:54:21PM +0100, Michal Meloun wrote: > >=20 > >=20 > > On 22.11.2025 19:45, Konstantin Belousov wrote: > > > On Sat, Nov 22, 2025 at 07:01:03PM +0100, Michal Meloun wrote: > > > > > Would you please gather the same ddebugging info, with this = patch applied? > > > > Oups, sorry. > > > > In meantime, next round with he vm_map patch finished = successfully. > > >=20 > > > It was still the case of coalescing previous entry and the = mapping. > > >=20 > > > It is weird, the patch ensures that there is no pages in the = object > > > backing the new region, and due to the ensured properties of the = object, > > > there should be no way to create pages under us. > > > I am almost sure that the provided patch is correct, but it might = be > > > some additional cases that I miss. > > >=20 > > > Please apply the following debugging patch, it includes the = vm_object' > > > part. Instead of allowing the corruption in userspace, kernel = should > > > panic now. Can you confirm that? > > >=20 > > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > > > . . . > >=20 > > Unfortunately, KASSERT doesn't assert on failure. Don't hit me, = please. :) > >=20 > > . . . > > ... > Please in addition to the patch, enable debug.vm_check_pg_zero. # sysctl debug.vm_check_pg_zero=3D1 debug.vm_check_pg_zero: 0 -> 1 # sysctl debug.vm_check_pg_zero debug.vm_check_pg_zero: 1 # env WITH_META_MODE=3D make -j10 buildworld --- buildworld --- . . . Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaCodeComplete.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaConcept.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaConsumer.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaCoroutine.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaDecl.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaDeclAttr.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaDeclCXX.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaDeclObjC.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaExceptionSpec.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaExpr.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaExprCXX.pico Building = /usr/obj/usr/src/i386.i386/lib/clang/libclang/Sema/SemaExprMember.pico : = /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed = assertion: "p[i] =3D=3D 0" Abort trap (core dumped) *** [Sema/SemaCodeComplete.pico] Error code 134 . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Nov 22 21:55:47 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 4dDQrl6F4Xz6HfpN for ; Sat, 22 Nov 2025 21:56:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4dDQrl2vN1z4K07 for ; Sat, 22 Nov 2025 21:56:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="FT/QuSTH"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763848560; bh=pIb9CvXhPk64vvpwktw66Srn9Y7q8WqvOe6bs2d7Uxg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FT/QuSTH3Q6/oGOj4/UGIwpQ+ilZPMxVeFckdVDpfRElOytH/omF+XLyKwhuJQTI0sy0tjWjj8HXEyzMa4qC03VHWvCYpalSiC/Ttx+Ry5TsSg3WM4oWO63H3tdFmLIfqbEn22hMW3dbuKMpKvHJmXCpf/bqEMO18RuO8h4Ads9BrAigCSckyUlUwCNFl0RKmAxhkgA+Xi/DE4s5EOY9QaHAN7aWFwTr9+M5EIZ+gkmEcIMDL/y5PqvektpWnhJsEutYxd4uhAfT7HtstvYR1tnIvn8bgEKcOE0kpnt4HU5EEY4t7rY+M0ymXDxACA7+mcDWydftkvQ54oOqPzbnZQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763848560; bh=aFzQSUUAuOkvPHfAGc4uRlpiidhTitLrkNB5x01oe9Z=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oM4cAdSmuI92hT93YlGjMLF4YabT2GYNjk/mdkrz6P1EF7a11AYdyLJbtwLCPeV3p328sOqr3zLkPubVO5Iq8cYqFfl0GZde60fJnYsJYEXPieWiycS0voU6tGGtmp/trx59JIIrs850tWGW1kJwzvaNxuxdGALsV6/Q+n67y8ROw9sNLbbw8+LuDn0txvpLf2mWYQQIyFwmx+9k0nFnnbblq0GVRTn/nsQ5LfOlpAf/hU4WaTtqaBR9xe75ZFELxziir71Da6kUjqCW1U6aPG7ZvBBmsXhQhSwQSfbiLIqUrEGvnzJnp5tGO5f2rEayYidBTs56xtXXEe3yuk3UDg== X-YMail-OSG: n7VjKioVM1nKzxM5UDKM.f_.xWzV8BQV8FKRLBlV2FDdbedTP1C9XbPJALQ0oou FYCFd_7SZokKQMUD0RvPExY1rFlNIjEZom49sBYfVp_la.weCJkY1AZbsu_4V46vd4UzIm1vRBwk xe_A.yhpdeK.RWBAiViN8QbWOtD.hTVllg6RVXPexlABCo7eMoZDBHbozPSKpaA8h8BCWJkSN83z .rJ6gEIU3ZCO6fROwnURoV_hjrF_bH7AEXWgWPCJ__qM7Jyzoyf74g_pYlmXZbkcvzwNXpApIwpW PWAyKpDrX5Wr1SPD1ae_e1ZDE32frvxYYfk7nV9IPjNFSsIRFaq5D1Am8Pus8fb0nnn9qNNWXvdl sFrIu9IA2ParP1nMw19T7Ryi_Owyf0pqJw3VSiTIEsREsHafANh3bTeCwl1kCCj5b3Rf79xU24Bl owGSuRlt.3iO.VubuMFDf_ZAJ_syAriPpUKvrfShbvA6AeoHW7SUaIT0e9TX8HfEt3tjv7b0ELtc MutZqU6KfzCoPMZRcD1F28KZ9Y7dA6GHgMSCwLNttzY7v8iQVUy8sxVP2.Z0AkrUOBm7pCNo8KVw _rN4tDJOItuelYZmXpTfpU_fK71Ket4pVahcVVhXiXLi.oerjihKjlfDsY.0ipQmQog5SaR5KTfV ckuCp_EFmyVg0cTA8JLzNj4ZALlaMPwhcclh9LjUXeaDFrNNwfNodSxwNN5vK122BTe__mv7GILx Jz6qzz6C7dD7_oXwE52crdiJPYYsPQK1K4cZ5vkSkY333Gjx_LTHfZ1BpQW21KCjR1F8cmPHcy4b vMwsDPWITaJvkxmin6PcWfRK83CIjcLKhtoAb33aeEMQMO7Ff_29iLXxj0vWy224BqCLzKjWPLxV dkLK6GnaCE6L1TqVL8fk.SAqoPYmp073ICEumtXZcLfN45ArOo7EXn092IaBgDkKXZykxqyBP546 d.X0kyW3yNTCmB0kggrRjEm5SqeL85qOlNyyGRqxFpTI0XFs1E39HYbOyPRHSgZY4QatqzmT0f04 9eJ8n5pPkQC1KP.xhEbD.5yZGtoXLA7Tfx8zq._S1U05QC9LhTXGwIqrcuUJiLHXuI1GJE.kI3nO Gi.cZ_J8YE211zii9NsZJ5mgZsTaGulB3HW8X0JB233GalthoUuXkbeatIkvgbjZAK20EVMX.WwH 4vFgvGdrd2ZJcCMhcp0O6PFeLWg4us3vZw2tUNEqlKl6kjAjZ54SV3NOr3AYZz9wMdm4zpfst27F itwiS1pBnzYMNe3.LcG48tw0LqjnQMaiyNbw3IhcnL4f1f.dsLQ.bHtSQRkz.O8rAHZI3tQbLS4Q GylEJd2gq2LQh_GVze.p0vfLXL8saRq95.NxGBs2Y2Wrm45Ou6vtZiyPotbMqj61bBqIVE4mSgPP _AzCLkvf5d7cDaN4GvOUziZCv9zwvwzFrKMMkms2zyoZypbD6l2KV32UWwjNXRa_AR8Fmh0UJrto CW8B5fl4ZrRnKfwbTBLnehEx0DHtu6Lch1HixmZ5Y0R8UP3OlSm4_iFczeVGPMY1IeN3d93dmj01 BJjdd7GB5cHIzm0iTzDUU.frUnOQWLK2f5sUCvWxGoHfUQtNKwY6ZikcfuvCPutMQ_UvB7JHrY76 KBSoL7KB.a3IC23y13zhzXXsVobzWPKLnZ5WC7pyEzv5cRI3c.i6IuJ1k12GMquZGJe2hbYMg4FN r0DHBqcNYKbpiH8MT9TlECnhRBXWaPIfLdni1a5O4A7gXJymp_6eluJLMWwVi5.TwGFNAw3VY9eq eQXOjXTmB.Ys1qYzzB.i7LMP__rG92Uq40W_ePBpJs2dOaOoj5kyQAn.OWgyhfsQF.GD0qiIMjp4 TookroaPuuUORBJ6WT7WfZVfMpF5b3kGGzmr90YGgZn09s8VNVHGNc_O_fAg4KrBpTPekJY6V0V0 lehHFfHITEe5N_Ru_wKTzya6.VmNNnlDfooMzG8lRrdQo_DEA9anov3LYzHQXbtVhbBGZutwuEqe fWG7eT98AtZrufOxQMRrkvAaBYXsuMTL0sIQuzBOdv9yi1SiKJkezgnhpMlv2egMYBl5yjLZxw5F 90BGQNcHhVA85wenxwX4sUmN1W6NSsmTbqA97my82EYUkk0md5iXmh_bhbY_O13CuPEzTlRG2C2h J3F0UFf4bvenI7HVNIUJqnlef1zxtGtTPtkJh30Gkp6jzRDbu5XMnAaNdAhdChxEfIJszkyyZEtx vGbXrnEEQvd5tIeCs5LuwW4iZhehJdbebAhwxK6ERN5k6EcK8BQGk7rMeBabX4314D2J33lJ_tbt 5sp2UFPxIdg-- X-Sonic-MF: X-Sonic-ID: bb99097b-89d5-4f4b-a29a-334f312e36ce Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Nov 2025 21:56:00 +0000 Received: by hermes--production-gq1-fdb64d996-jgmsv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4b912a31d26f4102a1b2683fc2275334; Sat, 22 Nov 2025 21:55:57 +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: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) [*** latest update working in i386 chroot test ***] From: Mark Millard In-Reply-To: <75CEABED-3CCB-4DB9-AC82-5980696C2A06@yahoo.com> Date: Sat, 22 Nov 2025 13:55:47 -0800 Cc: Michal Meloun Content-Transfer-Encoding: quoted-printable Message-Id: <48467E94-9A3E-4287-998D-EC9360337275@yahoo.com> References: <75CEABED-3CCB-4DB9-AC82-5980696C2A06@yahoo.com> To: Konstantin Belousov , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.864]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4dDQrl2vN1z4K07 Konstantin Belousov w rote on Date: Sat, 22 Nov 2025 20:41:27 UTC : > On Sat, Nov 22, 2025 at 10:19:38PM +0200, Konstantin Belousov wrote: > > Please in addition to the patch, enable debug.vm_check_pg_zero. >=20 > And use the following patch (one more hunk for = vm_object_page_remove()): >=20 > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 6b09552c5fee..76808b5ad7f1 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t = object, vm_ooffset_t offset, > (vm_size_t)(prev_entry->end - prev_entry->start), > (vm_size_t)(end - prev_entry->end), cred !=3D NULL && > (protoeflags & MAP_ENTRY_NEEDS_COPY) =3D=3D 0)) { > + vm_object_t obj =3D prev_entry->object.vm_object; > + if (obj !=3D NULL) { > + struct pctrie_iter pages; > + vm_page_t p; > + > + vm_page_iter_init(&pages, obj); > + p =3D vm_radix_iter_lookup_ge(&pages, > + OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start)); > + if (p !=3D NULL) { > + KASSERT(p->pindex >=3D = OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start = + > + end - start), > + ("FOUND page %p pindex %#jx " > + "e %#jx %#jx %#jx %#jx", > + p, p->pindex, = (uintmax_t)prev_entry->offset, > + (uintmax_t)prev_entry->end, > + (uintmax_t)prev_entry->start, > + (uintmax_t)(end - start))); > + } > + } > /* > * We were able to extend the object. Determine if we > * can extend the previous map entry to include the > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..e87047f9a380 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -1988,7 +1988,7 @@ vm_object_page_remove(vm_object_t object, = vm_pindex_t start, vm_pindex_t end, > (options & (OBJPR_CLEANONLY | OBJPR_NOTMAPPED)) =3D=3D = OBJPR_NOTMAPPED, > ("vm_object_page_remove: illegal options for object %p", = object)); > if (object->resident_page_count =3D=3D 0) > - return; > + goto remove_pager; > vm_object_pip_add(object, 1); > vm_page_iter_limit_init(&pages, object, end); > again: > @@ -2061,6 +2061,7 @@ vm_object_page_remove(vm_object_t object, = vm_pindex_t start, vm_pindex_t end, > } > vm_object_pip_wakeup(object); > =20 > +remove_pager: > vm_pager_freespace(object, start, (end =3D=3D 0 ? object->size : = end) - > start); > } > @@ -2189,13 +2190,19 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, > next_size >>=3D PAGE_SHIFT; > next_pindex =3D OFF_TO_IDX(prev_offset) + prev_size; > =20 > - if (prev_object->ref_count > 1 && > - prev_object->size !=3D next_pindex && > + if (prev_object->ref_count > 1 || > + prev_object->size !=3D next_pindex || > (prev_object->flags & OBJ_ONEMAPPING) =3D=3D 0) { > VM_OBJECT_WUNLOCK(prev_object); > return (FALSE); > } > =20 > + KASSERT(next_pindex + next_size > prev_object->size, > + ("vm_object_coalesce: " > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > + (uintmax_t)prev_object->size)); > + > /* > * Account for the charge. > */ > @@ -2222,26 +2229,13 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, > * Remove any pages that may still be in the object from a = previous > * deallocation. > */ > - if (next_pindex < prev_object->size) { > - vm_object_page_remove(prev_object, next_pindex, = next_pindex + > - next_size, 0); > -#if 0 > - if (prev_object->cred !=3D NULL) { > - KASSERT(prev_object->charge >=3D > - ptoa(prev_object->size - next_pindex), > - ("object %p overcharged 1 %jx %jx", = prev_object, > - (uintmax_t)next_pindex, = (uintmax_t)next_size)); > - prev_object->charge -=3D ptoa(prev_object->size = - > - next_pindex); > - } > -#endif > - } > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > + next_size, 0); > =20 > /* > * Extend the object if necessary. > */ > - if (next_pindex + next_size > prev_object->size) > - prev_object->size =3D next_pindex + next_size; > + prev_object->size =3D next_pindex + next_size; > =20 > VM_OBJECT_WUNLOCK(prev_object); > return (TRUE); This completed the lib/clang/libllvm /and lib/clang/libclang/ build activity from prior partial runs. So I started buildworld over after doing the "rm -fr". It has completed past the : /usr/obj/usr/src/i386.i386/lib/clang/ part of the buildworld and is continuing. So far so good. Is 15.0 going to hold off for the final form of this? Get an EN later? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Nov 22 22:07:41 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 4dDR671Cpnz6HgXs for ; Sat, 22 Nov 2025 22:07:43 +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 4dDR670Zv1z4Ltq; Sat, 22 Nov 2025 22:07:43 +0000 (UTC) (envelope-from mmel@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763849263; 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=8BGa64wfT2bvXUoPhcys6VRPnD9Wu1e3irNHnb+nnYA=; b=PBhVqcM6DZF2kGAMUJEJvRI9pLrQBAn9vAtAL8krHR87vBBv9TYzd+0uqC3Cpl8A2w2thK MlnhidGp+vficFbSTe+QOjzFBac2zNazG7QQFwGTzTsXHr6Ku34A+Sfze9BZ49/Sxyomdp Tg0koOEWNXuCQ1NsomchdfQtdPhX/QhEAlEX5Xdt3wmEscO6i5Z0Av+uq7b/Sa30zAVd4B EXuTC1PeMXVLZV8OcSd8FIwg/6yjaRqD2OZFH64TVvuyIq7IcLlCGhyqTiGRwvdJXc6TUC qW/0xjm91Loj9dt0+4HNA5Gq0hT42oVhJRtGIjh24+4Iyrg2mmYb7+gjNraOmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763849263; 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=8BGa64wfT2bvXUoPhcys6VRPnD9Wu1e3irNHnb+nnYA=; b=iumareIKyHGES0UDE3kqsEKO/ToRVuUYQ0ln4Xhu3C6ncMHtLnseXbm8VjbNm8oSyszKE9 5N6KqY82aiIeTlbisPy8i45jQNS+mAzHgoBXXZcmvuIh03z4M/pqme/9eCbz7qVYRrs36c 6t4jgr2iP9WZC/vGvCjjyHxuv6eM9n8cYDbfZuouG32Q7QvWXNNT2lqB57QGbXDZveuqWj 1Q+KSYSA27Hosflnp9ey1iJID7qvgyjstNk0qmUjmA7aJgWBrVuvDqg8T7D0gVvJ+DwNlo ZRCrzAj9rWopTrkHoqEpUnCcxZQRitLAPBgeAKoKEGZXH7va5WWsJxs4xZixxA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763849263; a=rsa-sha256; cv=none; b=YbU25ATtiMgqOs5GxAU9zAZXtHFj0eoEHx31skk/wm8dBWMI0cwZZc0RBhJ/sBBTheaC4m uWakXYW8/560JAW10jxqIgNCtJHECcJYxPkW/3CtpHfN5T+PkCSllfWHyqaqv5CTzuGcDZ J/o9DPB1riTf37F+axgExkob1GAJQS2q4+E3hFW49ULNDAj1OBtQF6U6x1qEzprPpXue37 tvKRLtBbeV/5DJh/2/O8FM3hkcBm0p0fPxX7qscPKrDwMfXG0cPCYZEsxJ4WzLOLDum4yX xffMrtsdngyYPWSo7+401HcgRQ6vSd9jWJJ+h3b72DTFit3BoBKYRsBSyVFQeQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (lety.radiolinkplus.cz [109.205.241.143]) (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 4dDR664fDBzysC; Sat, 22 Nov 2025 22:07:42 +0000 (UTC) (envelope-from mmel@freebsd.org) Message-ID: <9ef6253b-0f3a-4178-bfb2-65cc847ce652@freebsd.org> Date: Sat, 22 Nov 2025 23:07:41 +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 From: Michal Meloun Reply-To: mmel@FreeBSD.org Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) To: Konstantin Belousov Cc: FreeBSD Current References: <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> <9a864c53-0033-46d1-ad07-6b528115789f@freebsd.org> Content-Language: cs, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22.11.2025 21:41, Konstantin Belousov wrote: > On Sat, Nov 22, 2025 at 10:19:38PM +0200, Konstantin Belousov wrote: >> Please in addition to the patch, enable debug.vm_check_pg_zero. > > And use the following patch (one more hunk for vm_object_page_remove()): > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 6b09552c5fee..76808b5ad7f1 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t object, vm_ooffset_t offset, > (vm_size_t)(prev_entry->end - prev_entry->start), > (vm_size_t)(end - prev_entry->end), cred != NULL && > (protoeflags & MAP_ENTRY_NEEDS_COPY) == 0)) { > + vm_object_t obj = prev_entry->object.vm_object; > + if (obj != NULL) { > + struct pctrie_iter pages; > + vm_page_t p; > + > + vm_page_iter_init(&pages, obj); > + p = vm_radix_iter_lookup_ge(&pages, > + OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start)); > + if (p != NULL) { > + KASSERT(p->pindex >= OFF_TO_IDX(prev_entry->offset + > + prev_entry->end - prev_entry->start + > + end - start), > + ("FOUND page %p pindex %#jx " > + "e %#jx %#jx %#jx %#jx", > + p, p->pindex, (uintmax_t)prev_entry->offset, > + (uintmax_t)prev_entry->end, > + (uintmax_t)prev_entry->start, > + (uintmax_t)(end - start))); > + } > + } > /* > * We were able to extend the object. Determine if we > * can extend the previous map entry to include the > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..e87047f9a380 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -1988,7 +1988,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t start, vm_pindex_t end, > (options & (OBJPR_CLEANONLY | OBJPR_NOTMAPPED)) == OBJPR_NOTMAPPED, > ("vm_object_page_remove: illegal options for object %p", object)); > if (object->resident_page_count == 0) > - return; > + goto remove_pager; > vm_object_pip_add(object, 1); > vm_page_iter_limit_init(&pages, object, end); > again: > @@ -2061,6 +2061,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t start, vm_pindex_t end, > } > vm_object_pip_wakeup(object); > > +remove_pager: > vm_pager_freespace(object, start, (end == 0 ? object->size : end) - > start); > } > @@ -2189,13 +2190,19 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > next_size >>= PAGE_SHIFT; > next_pindex = OFF_TO_IDX(prev_offset) + prev_size; > > - if (prev_object->ref_count > 1 && > - prev_object->size != next_pindex && > + if (prev_object->ref_count > 1 || > + prev_object->size != next_pindex || > (prev_object->flags & OBJ_ONEMAPPING) == 0) { > VM_OBJECT_WUNLOCK(prev_object); > return (FALSE); > } > > + KASSERT(next_pindex + next_size > prev_object->size, > + ("vm_object_coalesce: " > + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", > + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, > + (uintmax_t)prev_object->size)); > + > /* > * Account for the charge. > */ > @@ -2222,26 +2229,13 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffset_t prev_offset, > * Remove any pages that may still be in the object from a previous > * deallocation. > */ > - if (next_pindex < prev_object->size) { > - vm_object_page_remove(prev_object, next_pindex, next_pindex + > - next_size, 0); > -#if 0 > - if (prev_object->cred != NULL) { > - KASSERT(prev_object->charge >= > - ptoa(prev_object->size - next_pindex), > - ("object %p overcharged 1 %jx %jx", prev_object, > - (uintmax_t)next_pindex, (uintmax_t)next_size)); > - prev_object->charge -= ptoa(prev_object->size - > - next_pindex); > - } > -#endif > - } > + vm_object_page_remove(prev_object, next_pindex, next_pindex + > + next_size, 0); > > /* > * Extend the object if necessary. > */ > - if (next_pindex + next_size > prev_object->size) > - prev_object->size = next_pindex + next_size; > + prev_object->size = next_pindex + next_size; > > VM_OBJECT_WUNLOCK(prev_object); > return (TRUE); uff, we have winner. All check passed. From nobody Sun Nov 23 02:16:28 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 4dDXdQ6PhMz6J2lf for ; Sun, 23 Nov 2025 02:16:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDXdP71FNz3TQ4 for ; Sun, 23 Nov 2025 02:16:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 209.85.222.172 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-8b2ed01ba15so285179085a.1 for ; Sat, 22 Nov 2025 18:16:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763864201; x=1764469001; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/Ql7X8c68BJfv0r3Vry+H6jLvjtOlOS2cgQ3xCjThTA=; b=g0I4210eq6m/UdWQcd8gB5satNlNyeM4q5WbMr+ARysuT4fyQdz+/USAbpIuYc1+3h A7QqKyTI2tI3nWaep5mYi3GKMzrj+1fui9Z2w1BJVSr5/47isLZXqKzdB/lspry8AGqV +kIV40f02oUsqW9D6WuNzi1m5hSfWQY2IKKaMQSrelNQROPCZqUcUVE+SQYGGGMQvjEg 1CBZuQVL8LGQXPdbx8g/3KBc9EDYskZ6FoqQX7VmraoXYg4aVeUz1wdpDYNs3tZSYQSk v2jWjxvPk2ufiWde//iYaK/oIiyid/3QLm7zThITqawndAVdeIC1ssVjRakuOz0aj6Fi ge1w== X-Forwarded-Encrypted: i=1; AJvYcCWMJA2/E2UaSIOnXkd3pTzbcDWIAZqhU3x26+uTzSB2vFPPlBE0afhTDW8iFMpj3RkUmvwMru6LGya4xmDxbEc=@freebsd.org X-Gm-Message-State: AOJu0YxdR3NjwIuuopxnmyI2jBVg3nIggrdGmEFSJZK2RDKKFsbIzPA+ vKu3bhzpCIVcBzSoYNGLOsCJhxV2Jxv0P2T+SaNC8jLkdlTg4dUllCDfySOCYz6fpak7lol5bqf 8GSESGk9ukYX02WRYWyJWwFHK3KxrAZI= X-Gm-Gg: ASbGncuBxeCi3vt+ulyCzpPJTK9dOPkyFLza0CsrWfUyw38EIp9tgd6MUA8duCO041P n02RxR1ZDaIZ10WP+IOvdPbw3KK/2P/2YjAjDyEhmob/Tydbh85eAyoF0C/UMgDZxMrvyCac7FC 3aO8/p9Opj0QtrW7knDpMze8Zi2FR/GoMcCGob/9YSYRU7uiRxCsKNbLkRDUpeW5Mlek28i7ez0 2P+VmwG6zgx2p2Mg/RYE6sKY3rcgzUycTt3BY1PR/dIUDnSB+yiwW3WQ8UQLD7l4pKJr+YZZuQK J2+RE7oGaMZnYim3IZAD6azOZZzf6w== X-Google-Smtp-Source: AGHT+IHNx614TgIIERq2IHGviG3KGk/mvT7TYYvZf39XTxUeVC9ANl9xt7+TPRd4uzpSer7cAR4KiKz3sXtASlBu9Fk= X-Received: by 2002:a05:620a:1708:b0:8b2:f090:b15d with SMTP id af79cd13be357-8b33d4aec0dmr940716685a.80.1763864200515; Sat, 22 Nov 2025 18:16:40 -0800 (PST) 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 From: Adrian Chadd Date: Sat, 22 Nov 2025 18:16:28 -0800 X-Gm-Features: AWmQ_bmN8pW0yNmrhB7WaS1C8fpn9M1ZQcfFKzyjWESgCJi_ruR4CbJNwZftcJ8 Message-ID: Subject: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver To: FreeBSD Net , freebsd-current Content-Type: multipart/alternative; boundary="0000000000001a942d064439a339" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.99)[-0.993]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.172:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.172:from] X-Rspamd-Queue-Id: 4dDXdP71FNz3TQ4 --0000000000001a942d064439a339 Content-Type: text/plain; charset="UTF-8" hi! i've ported Kevin Lo's openbsd driver for these realtek chipsets to FreeBSD. It works well enough for me to use on my laptop w/ RTL8125B / Killer E3000. I'm now opening it up to others who are willing to build/run a kernel module to test the driver out and report back. The driver source is at https://github.com/erikarn/if_rge_freebsd/ along with build instructions. Please note that I'm only running this on -HEAD and I plan on landing it on -HEAD before /maybe/ backporting it to stable/15 after the 15.0 release. I've no idea if it compiles or runs on stable/15 or the 15.0 pre-release images. If you're willing to give it a whirl then please do and report back but I'm unlikely to add explicit earlier source tree support in this repository (as again I'm going to land it in -HEAD.) Thanks! -adrian --0000000000001a942d064439a339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi!

i've ported Kevin Lo's = openbsd driver for these realtek chipsets to FreeBSD.
It works we= ll enough for me to use on my laptop w/ RTL8125B / Killer E3000.
= I'm now opening it up to others who are willing to build/run a kernel m= odule to test the driver out and report back.

The = driver source is at=C2=A0https://github.com/erikarn/if_rge_freebsd/ along with build instru= ctions.

Please note that I'm only running this= on -HEAD and I plan on landing it on -HEAD before /maybe/ backporting it t= o stable/15 after the 15.0 release. I've no idea if it compiles or runs= on stable/15 or the 15.0 pre-release images. If you're willing to give= it a whirl then please do and report back but I'm unlikely to add expl= icit earlier source tree support in this repository (as again I'm going= to land it in -HEAD.)

Thanks!


-adrian

--0000000000001a942d064439a339-- From nobody Sun Nov 23 02:44:36 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 4dDYG31RJlz6J4LZ for ; Sun, 23 Nov 2025 02:44:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4dDYFz71KBz3YSR for ; Sun, 23 Nov 2025 02:44:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=M+KUdlUu; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763865892; bh=D0/9sFlrcV17p6N9Ide81Wy+9Km5bSkD0AsSKkzzhiA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=M+KUdlUu10mnWMeNINUwATkOkbbZfduM7LtFBi1Erpyv8EX0ntqJCj9tDU+9wI92FEk9H91TK8YbG2KXMGyjZkCwotOQcWjavrzmGGzRmH9TRafXIV5svkGiSHihoTeP1Ic/WhasIPoAf2q9/YBjNUmv/akGjOO0RfVnkBsL+pyMgbw8KiO/p/gaykyMSb3eMqi4EHVUvqbB+Lstc6Ozk7I341TqfXkW1/gHclcdL42m5HVm7QVts/9+YrXLdJwaQvfUOC0O9pSnRkY8ZI3/Jpt0Zz2Lvee/t1gSZp/dclV0HVZvC7u19o45we9I4kj+DMwHb0MrE0uxpbqqcatxFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763865892; bh=q+ipamb8EYB8q+h3h8iH+xNtfVVqXhk0ntl3nDjw4v5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eZGhjgVOvBZBboLF44KXJaSXuB7axIeY7e4WhzhPtIBHvFGu80YOxojw0ruLIt+syUAb82+maxNXllBOMzY6pS0zn/TO/KqCS6jpjOw+XjcheJyKc4r1FAm3jRIu36sO5pkx9o1yVr/mlZfsqpcPcxoNDiyZJ1+kEt+WlKIF4XRX70F0HOCUJ6DkySmA9Eooq7aDNKlv/LzpjWadzzYl6GvmKQNNgkrSvg5RMHholFI6bLGd5aaCWBQpfCHzC1QSQmfqHEzI7I2nikJEVmlBYkf9pvQ0PEHG06ppOfkkP++qB8RN/0+kMhHEwex2BHKLcxtTO4a0Ni+2PEW3VRZw2w== X-YMail-OSG: XTb7vuYVM1lw23YrZd2hqi59j9xtiMaW918zBPDohN3jmCm4hG4RCs55nQAJf_S bKUZqAsjayXkTRMeOC5dfFmIdNA8N6nopKuoEJlvI0TLOne_3ZJVQfDpsuKPsrUEst6mFNJECg6z O9vmxLKOPxpMMtNVCF15SopjnHvq9IPab8owo8Sm2OfEsnK0xU88ND6FDO3b_ZI.eC3u8rG5XXIn M4iEG80mkTBKhC4lVSD5Z9OU41seX5tr9WzjTKXvSHMbPsCrjotU3tZ1Zh4wx5wbvrdZ4.yBBtuK cKttQODUFEPTaWKIl0X8nv_qaqFV5f96yB8n0Zmu0EhaNW21oobxi7zg13Ju2FOmnzydTPuuofM7 lmJ3mGzceie.bBMyc7wupDxRJ.nVMoOqyn1V1kGIHy5xs7Kjlvq2NKiKSuiL6AzGPm36RwSL3.Cz d8Xj.om1tIAYyn9rtwR9JnfP4WVpNMu2WgyE6w9GMb0zX97TzJ3NeDrqAwTUud2QaV1kpDT_RRQb 1IGz3nmXZonH7o35rSo75xoxTCAgD2XmHFDAAFPVFLqiedr4Nzlg.3Mp.INCjtWNExBQvnaAcCjy AdupdZnpR1zGtZ0bBuBGDLz4i._S69uN_1m7rEjI5VfNxqvWsM1bXQFyy3RD4pdyUyf8JK.Bt40i SA4NHVqOYf5RKjFmbicl.RvSQifXLwmoX42xG.dq1tcutAcqLh.zCG4MTCzcKUoUAMu0f.oV.Eg_ J0Ursmhedfy34O8gay8djNE5wXHPBEQOgnN99B8uERzmmfQULs.Lfb19aVr9y3yvbS_EGR1vknrr s86ZefnDt5GeLRFFRb9RM0AJdTjV.uhHgVVok_NoGdYRWtRu1eyk__zzT4OliaOim0RoXQ96WMrG nOsie6jOZx2.soDjM1.Pv43GxOWkxZ4nVrDgSVovhey8PpLpUrZxj7QLqyiOwF63eYYrhF_oqA2k .OQ6ib0YBCjRi0E_12F6gSuSBhOsm1PNYL8ot5oSpuWJ2HGXDknW55hbGPAglBqXFkgDyP2ugGm4 RR_MdYdOBZRAh45_P7gX9dGa0KHW8LmFn1X_VldaHiF_7Q3UFoFqZZo0nFQnBA3RjIRO5eNez.WF _HVVwIkesxzAJ4c3l0359DxoKvVIM1irGSATNzN9jypdiIiAEieQu1FR_HdmaNWrzzgyzgNdUdmf EBIx9WuXUyfONEgtB_fMYK0uGXY2D2kr5QI5aloYlkjkrPQfO1bppHwkHoo_8jkUs8PO_DLkXQQZ CGmwbR9_6qP0KW93wYbGHTtUw.Y4gbImnksEapDINQPtf3UNvlWf7DvC_kgXb_xEf_2K10ZhitLA MmoRDhJmF.50NGt8mMKNJuOfDuPUelnihP4G5rGkTtBlPwbgrsEw6QunFfWDDHn70zjUUuFP_rCZ pHZeuvWSMO9M.SET8G9jBm0v8OoPMAcvJhC0yC_VkfL3Yn2l2uuaVHyQW313jHwq5kxfoiX.Q4Q_ VDkB4TgpE2ac_pa_ariOFYL4.V2FUeh9zlIFm.J1oRiaJqzbk1jL0AysUlOYq5XEAA93gAz1rHgp 3eX7ik4GlIPAS_mP2hxUUaVVCYch3UsNQJuvYqSvgA3MOwyw8KxCqOmhwXaPLkjbU0MU3Juy6dXh n91X7u1THY57ebtK8bo19LdqEHPv1ulM4czF7y4kTvC7XauqfVrDneSEdVkpRdfAnCQ9mtaa3AM_ YRU24Nl5YR7CyswFQtz59y0NumGlPthvwgNfiPFHx9k7lNQR_.Bss0pAyvNnvTMftUqAzcbhK8o5 2Cnac2fNCKL41ESMkrIVEog0MUILJxrYR3yfRZk5EOglBpRgO120R3wJoKJqUBG4WJOYmBF0ZT_G sQgfcQ86TOFAFJgxtHu7N8ZeoIPRt_IZ6WZ1dVBlQYDG_lAnx3F4G8p_6rfggYUxLH_uEwQ5yjG8 JAgzGCZ5DHLdEryxtZwzoT2lrChKtXo.gDuZEuFYPUCsUGKW5ByDf1.ovfdXhpX2KlK3CTolD7JS ugJ0S_.SeeggRIfrreiVhnQKJus4xGGRRmj6_S4j3YXK_KJIEmzCyiVVqFYvKhHYKBygkjLSpjUn 2btu4u4C2pFz5wLHKyqjStNJQBgW.Mn4UjL.P3cjyRpnrwesumZzdh920mmtuGBwUJ6yfidMneQI _MAN_BCSFPJN4Hc4CecHPy7.GwDyKWceHIbM5XFO3COrEDktz7EvTOvUOnnCuSfkyl2NED1Mq_rQ bp4fahu4.koF8vP5e7P3HFRqWDc30AanQ7ZExaZAobary2sxfezoENn.ULyTj_O_Q1A_jjWu1.bq QTpfV4LFPz7Zu7iyw X-Sonic-MF: X-Sonic-ID: 94d09ad1-de6f-4b50-b107-4c46ad940947 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Nov 2025 02:44:52 +0000 Received: by hermes--production-gq1-fdb64d996-8w8lr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 841f66cef50f011e8857eca645269cb8; Sun, 23 Nov 2025 02:44:47 +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: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) [*** latest test patch update working in i386 and armv7 chroot tests ***] From: Mark Millard In-Reply-To: <48467E94-9A3E-4287-998D-EC9360337275@yahoo.com> Date: Sat, 22 Nov 2025 18:44:36 -0800 Cc: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop , "Herbert J. Skuhra" Content-Transfer-Encoding: quoted-printable Message-Id: <3D910723-3325-425A-9E72-2F6DE99D1067@yahoo.com> References: <75CEABED-3CCB-4DB9-AC82-5980696C2A06@yahoo.com> <48467E94-9A3E-4287-998D-EC9360337275@yahoo.com> To: Konstantin Belousov , meloun.michal@gmail.com, FreeBSD Current , Warner Losh X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.47 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.969]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org,bsdimp.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from] X-Rspamd-Queue-Id: 4dDYFz71KBz3YSR On Nov 22, 2025, at 13:55, Mark Millard wrote: > Konstantin Belousov w rote on > Date: Sat, 22 Nov 2025 20:41:27 UTC : >=20 >> On Sat, Nov 22, 2025 at 10:19:38PM +0200, Konstantin Belousov wrote: >>> Please in addition to the patch, enable debug.vm_check_pg_zero. >>=20 >> And use the following patch (one more hunk for = vm_object_page_remove()): >>=20 >> diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c >> index 6b09552c5fee..76808b5ad7f1 100644 >> --- a/sys/vm/vm_map.c >> +++ b/sys/vm/vm_map.c >> @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t = object, vm_ooffset_t offset, >> (vm_size_t)(prev_entry->end - prev_entry->start), >> (vm_size_t)(end - prev_entry->end), cred !=3D NULL && >> (protoeflags & MAP_ENTRY_NEEDS_COPY) =3D=3D 0)) { >> + vm_object_t obj =3D prev_entry->object.vm_object; >> + if (obj !=3D NULL) { >> + struct pctrie_iter pages; >> + vm_page_t p; >> + >> + vm_page_iter_init(&pages, obj); >> + p =3D vm_radix_iter_lookup_ge(&pages, >> + OFF_TO_IDX(prev_entry->offset + >> + prev_entry->end - prev_entry->start)); >> + if (p !=3D NULL) { >> + KASSERT(p->pindex >=3D OFF_TO_IDX(prev_entry->offset + >> + prev_entry->end - prev_entry->start + >> + end - start), >> + ("FOUND page %p pindex %#jx " >> + "e %#jx %#jx %#jx %#jx", >> + p, p->pindex, (uintmax_t)prev_entry->offset, >> + (uintmax_t)prev_entry->end, >> + (uintmax_t)prev_entry->start, >> + (uintmax_t)(end - start))); >> + } >> + } >> /* >> * We were able to extend the object. Determine if we >> * can extend the previous map entry to include the >> diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c >> index 5b4517d2bf0c..e87047f9a380 100644 >> --- a/sys/vm/vm_object.c >> +++ b/sys/vm/vm_object.c >> @@ -1988,7 +1988,7 @@ vm_object_page_remove(vm_object_t object, = vm_pindex_t start, vm_pindex_t end, >> (options & (OBJPR_CLEANONLY | OBJPR_NOTMAPPED)) =3D=3D = OBJPR_NOTMAPPED, >> ("vm_object_page_remove: illegal options for object %p", object)); >> if (object->resident_page_count =3D=3D 0) >> - return; >> + goto remove_pager; >> vm_object_pip_add(object, 1); >> vm_page_iter_limit_init(&pages, object, end); >> again: >> @@ -2061,6 +2061,7 @@ vm_object_page_remove(vm_object_t object, = vm_pindex_t start, vm_pindex_t end, >> } >> vm_object_pip_wakeup(object); >>=20 >> +remove_pager: >> vm_pager_freespace(object, start, (end =3D=3D 0 ? object->size : end) = - >> start); >> } >> @@ -2189,13 +2190,19 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, >> next_size >>=3D PAGE_SHIFT; >> next_pindex =3D OFF_TO_IDX(prev_offset) + prev_size; >>=20 >> - if (prev_object->ref_count > 1 && >> - prev_object->size !=3D next_pindex && >> + if (prev_object->ref_count > 1 || >> + prev_object->size !=3D next_pindex || >> (prev_object->flags & OBJ_ONEMAPPING) =3D=3D 0) { >> VM_OBJECT_WUNLOCK(prev_object); >> return (FALSE); >> } >>=20 >> + KASSERT(next_pindex + next_size > prev_object->size, >> + ("vm_object_coalesce: " >> + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", >> + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, >> + (uintmax_t)prev_object->size)); >> + >> /* >> * Account for the charge. >> */ >> @@ -2222,26 +2229,13 @@ vm_object_coalesce(vm_object_t prev_object, = vm_ooffset_t prev_offset, >> * Remove any pages that may still be in the object from a previous >> * deallocation. >> */ >> - if (next_pindex < prev_object->size) { >> - vm_object_page_remove(prev_object, next_pindex, next_pindex + >> - next_size, 0); >> -#if 0 >> - if (prev_object->cred !=3D NULL) { >> - KASSERT(prev_object->charge >=3D >> - ptoa(prev_object->size - next_pindex), >> - ("object %p overcharged 1 %jx %jx", prev_object, >> - (uintmax_t)next_pindex, (uintmax_t)next_size)); >> - prev_object->charge -=3D ptoa(prev_object->size - >> - next_pindex); >> - } >> -#endif >> - } >> + vm_object_page_remove(prev_object, next_pindex, next_pindex + >> + next_size, 0); >>=20 >> /* >> * Extend the object if necessary. >> */ >> - if (next_pindex + next_size > prev_object->size) >> - prev_object->size =3D next_pindex + next_size; >> + prev_object->size =3D next_pindex + next_size; >>=20 >> VM_OBJECT_WUNLOCK(prev_object); >> return (TRUE); [The Email handling did not preserve much of the whitespace in the above diff.] > This completed the lib/clang/libllvm /and lib/clang/libclang/ > build activity from prior partial runs. So I started > buildworld over after doing the "rm -fr". It has completed > past the : >=20 > /usr/obj/usr/src/i386.i386/lib/clang/ >=20 > part of the buildworld and is continuing. >=20 > So far so good. >=20 >=20 > Is 15.0 going to hold off for the final form of this? Get > an EN later? The i386 chroot on amd64 boot-system test finished just fine: -------------------------------------------------------------- >>> World build completed on Sat Nov 22 21:58:09 UTC 2025 >>> World built in 2330 seconds, ncpu: 32, make -j10 -------------------------------------------------------------- As did the armv7 chroot on aarch64 boot-system test: -------------------------------------------------------------- >>> World build completed on Sat Nov 22 17:55:38 PST 2025 >>> World built in 11501 seconds, ncpu: 8, make -j8 -------------------------------------------------------------- (The -jN numbers combined with the RAM+SWAP figures achieved for each made for useful tests of the original problem.) Prior to the changes, each of those had to be restarted a bunch of times to finish the libprivatellvm.so.19 and=20 libprivateclang.so.19 parts of the overall build. The above tests were both made after the new assignment: # sysctl debug.vm_check_pg_zero=3D1 debug.vm_check_pg_zero: 0 -> 1 that enables some new, expensive INVARIANTS code. Note that the code for testing is not claimed to be the actual fix that will be used. It was for information gathering. As I understand things, the changes involved apply to all supported FreeBSD platforms, not just 32-bit i386 and armv7. It seems jemalloc 5.3.0 used the FreeBSD kernel somewhat differently and ran into a long standing problem: what it was doing should have been valid. None of the investigative update was to the jemalloc code. But it could be that, on review, tradeoff management could involve jemalloc code for all I know. As stands: /usr/src/sys/vm/vm_extern.h.orig /usr/src/sys/vm/vm_fault.c.orig /usr/src/sys/vm/vm_map.c.orig /usr/src/sys/vm/vm_object.c.orig /usr/src/sys/vm/vm_page.c.orig were created so that I could use them to restore my official pkgbase source (that is somewhat older). Side note: I've not sent this note to mmel at freebsd.org as it forwards to meloun.michal at gmail.com and: QUOTE Gmail has detected that this message 550-5.7.1 is likely unsolicited mail. To reduce the amount of spam = sent to 550-5.7.1 Gmail, this message has been blocked. END QUOTE I'll see if a direct send gets the same treatment. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Nov 23 08:07:35 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 4dDhQP3mjRz6JTn5 for ; Sun, 23 Nov 2025 08:07:41 +0000 (UTC) (envelope-from polyduekes@proton.me) Received: from mail-24424.protonmail.ch (mail-24424.protonmail.ch [109.224.244.24]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDhQP1MpSz44YM for ; Sun, 23 Nov 2025 08:07:41 +0000 (UTC) (envelope-from polyduekes@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1763885258; x=1764144458; bh=NzNdyoAkAgpiJSzygx3p0OfVNJQ0Kb/1bxYJcjONZkw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fFXEmWIoRa6E/hDBKHkZHhIvlokOIf+VsVTOKqfNRiWdibx9lsfpmHNE0LjkUtLbh /PKLR16FCK8Qsxu9XQA2q9qZz0elCcFM0XIH4UCUD2CRhq37w8bL1oAFrxs3uQnX6h bJ3PpIAziJDLI7/uKVry9ZMbdBjxGl1h085POe+Ap2JbPZYUp2Lo21f57R/eRFKu35 8fJ5mYnd7fBhkMLYpgyocNiPTDfp6lpH0UWEgHc41dQK8VIq6CwHUmOkv+EJG25VuR CtHES7fdYFwbOrgF+IXqbNeAGvbxurMDCDwFzpPK9BX0A06MhgibteMlMdJaISW8rv Sh9Vih2/1d1xw== Date: Sun, 23 Nov 2025 08:07:35 +0000 To: Lexi Winter From: polyduekes@proton.me Cc: freebsd-current@freebsd.org Subject: Re: changing from pkgbase to regularbase Message-ID: In-Reply-To: References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> Feedback-ID: 94987605:user:proton X-Pm-Message-ID: 12eb6b1b9db7ed74cabbd684ee47e5bad2d5f22c 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDhQP1MpSz44YM what is the correct way to depkgbasify? > Marek Zarychta wrote in d6ed185f-ed13-4a2c-a875-1b687a0f7b8b@plan-b.pwste= .edu.pl: > > > W dniu 22.11.2025 o 10:09, Tomoaki AOKI pisze: > > > > > I don't think disallowing de-pkgbasifying is a good idea. > > > > +1 > > > we are not disallowing depkgbasifying. > > > Switching from RELEASE to STABLE has always been possible. Why should > > pkgbase be an exception in this regard? > > > it is not an exception. it is entirely possible, and indeed quite > straightforward, to switch from release to stable using pkgbase. > > the only nit, which was mentioned in another thread recently, is that > the first time you do this you might need to use "pkg upgrade -f" > because pkg sometimes thinks release versions are older than snapshots. > this only needs to be done once, the first time you switch branches. > > > While delivering a limited or trimmed-down OS with pkgbase is certainly > > possible, the same is true when installing from source. In fact, upgrad= ing > > the world and kernel over NFS is often even faster and less resource > > consuming than using pkgbase. It would be a great loss for the communit= y if > > this old, seamless, and proven-to-work method were ever deprecated in f= avour > > of pkgbase. > > > we are not removing or deprecating installworld. there are no plans to > do that and there is no reason to do that. > > to reiterate, in case it's not clear: the error being discussed in this > thread is NOT a precursor to removing installworld support and it is NOT > an attempt to prevent people from depkgbasifying their system. > > its purpose is an anti-footgun device to prevent people from breaking > their system by running make installworld without first depkgbasifying > the system, which will leave the system broken. > > as i said previously: if you correctly depkgbasify your system, you will > not encounter this error message. it is ONLY displayed on systems which > have NOT been depkgbasified. From nobody Sun Nov 23 09:57:11 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 4dDks13Brgz6Gdwf for ; Sun, 23 Nov 2025 09:57:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDks05x0fz3JPD; Sun, 23 Nov 2025 09:57:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AN9vBDJ062451; Sun, 23 Nov 2025 11:57:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AN9vBDJ062451 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AN9vBOj062450; Sun, 23 Nov 2025 11:57:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 23 Nov 2025 11:57:11 +0200 From: Konstantin Belousov To: Michal Meloun Cc: FreeBSD Current Subject: Re: mmap( MAP_ANON) is broken on current. (was Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) Message-ID: References: <603e75f8-7064-4fca-8520-282331c20ec0@freebsd.org> <9a864c53-0033-46d1-ad07-6b528115789f@freebsd.org> <9ef6253b-0f3a-4178-bfb2-65cc847ce652@freebsd.org> 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: <9ef6253b-0f3a-4178-bfb2-65cc847ce652@freebsd.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dDks05x0fz3JPD On Sat, Nov 22, 2025 at 11:07:41PM +0100, Michal Meloun wrote: > uff, we have winner. > All check passed. Thank you for the instrumental help. Patches are put for review at https://reviews.freebsd.org/D53891 . The problems are machine-independent, it is just that 32bit with more limited address space and disabled ASLR triggered coalescing more often (does not matter native 32bit kernel or 32bit userspace on native 64bit host). I do think that this deserves EN, but first it needs to be reviewed and merged to stable branches. I checked that the problems exist on stable/14 for sure, I did not looked at stable/13. From nobody Sun Nov 23 14:14:12 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 4dDrZ30dk2z6H37p for ; Sun, 23 Nov 2025 14:14:51 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dDrZ14814z3qnH for ; Sun, 23 Nov 2025 14:14:49 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=b+xp5yhP; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 9612D2409FD for ; Sun, 23 Nov 2025 15:14:47 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 088C82402A8 for ; Sun, 23 Nov 2025 15:14:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1763907286; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=EE1t1uCWOcGOsMKufd//8cddOwuw4/wJKTPmL1TT3ZA=; b=b+xp5yhPx0maaH5zHoE1seZdIW1QT8yNgZKt0MPekbpKJ2rFtBo9TnETNym9k5YkqrbkhZ ilzlyb8Gkge6m307XzJjTotQPrcuQT9tVg1uneclSaf/8+ZTCUMSVv71YvpyCnyso6WCm4 Z+yO5RG9Oo7QEw4FpoAXP+l9i6WQs/DI06njBvkWY6V1ivFlbr4GoIQ7zjT8NI9CNgxwMB 3CCboIka8BmsgH6eZ2MnTMkwTZq8sqrub7j7eaglV2pSni5MkCuAaUg0HCcN0LSpolCGyN tR5KlIMpN20jVbNacwv2eC6hRN0JICL6GjAPpO3ItNMJql95XdNO3M/asP760A== Received: from thor.sb211.local (dynamic-2a02-3100-2fbf-eb02-8e84-ead7-c851-e133.310.pool.telefonica.de [IPv6:2a02:3100:2fbf:eb02:8e84:ead7:c851:e133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id B8495240252 for ; Sun, 23 Nov 2025 15:14:45 +0100 (CET) Date: Sun, 23 Nov 2025 15:14:12 +0100 From: A FreeBSD User To: FreeBSD CURRENT Subject: freezing on unmountin ext2fs USB device Message-ID: <20251123151439.361dd84c@thor.sb211.local> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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: multipart/signed; boundary="Sig_/RLKUCDiWvUv.OEFy_HFWikH"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: fa9353 X-Rspamd-UID: 68401b X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.70 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[walstatt-de.de]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dDrZ14814z3qnH --Sig_/RLKUCDiWvUv.OEFy_HFWikH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun Nov 23 13:= 56:23 CET 2025 amd64 I'm running into a serious problem when mounting an ext2fs forma= ted USB Flash device (512GB). The devince contains files written by a Linux system, mount= ing the USB Flash via extended4fs, the size of the written datafiles is > 128GB. Deleting tho= se files larger than some 20GB results in an I/O error reported by FReeBSD (# sudo rm /mnt/= USB/filename). Unmounting the ext2fs after deletion (sudo umount /mnt) results in a total = freeze of the box. No crash, no core dump, nothing. I waited almost an hour hoping for recover= . I have to physically switch off the box. I checked with other USB flash I have at hand, one Samsung 256 GB, ZFS - no= problem, another 128GB, UFS, no problem and several much smaller (4 - 64GB) with FAT or UFS = filesystems, all no problem. I can not figure out whether it is the USB flash drive itself, the size or = the ext2fs itself causing the problem. Does anybody see similar problems or do have an tip to investigate without = risking my box' health switching it on/off on failure? Thanks in advance, oh=20 --=20 A FreeBSD user --Sig_/RLKUCDiWvUv.OEFy_HFWikH Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaSMWzwAKCRCxzvs8Oqok r/87AP9g6m9DHiHZ4HU1nXOTw6Sb2o80A5bh8p0YtCGeSle3HQEA7epWsrP+tZp7 d0QKPK/UoXm+uYNS3n4v5nzBLiYtEgA= =5cxc -----END PGP SIGNATURE----- --Sig_/RLKUCDiWvUv.OEFy_HFWikH-- From nobody Sun Nov 23 17:12:08 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 4dDwVf3MTKz6HKp7 for ; Sun, 23 Nov 2025 17:12:10 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4dDwVf2qmPz3Crw; Sun, 23 Nov 2025 17:12:10 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763917930; h=from:from: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=BqloJ5nFij50xG/TLfgHXhJrTMOiagUiEji4EyQKC+A=; b=Sg4sL3oRe34XiqKINI9G66MmINX4K0XhQsLOpiIDsuALILF6n3vyn/gy1A7gm270PG/acD RSpx0ihzoP4DFY1t2tPc4N02jdgHKq93x7OUQjOJez37KbbquE1rL46vo/jK2eMEIdtbpM ywEs+CSapvpQ7gDvaKWUmEfUM652UA0tSZP2ZBzgtgc5Q49sHDf2+qOooy4rU6mc0QzRDi zITWJ+icGuT2+QWml4KmnUZOSQBLn9nQ3mdwbk1LH0n1wnUKF3UCN5jH+kvSmSZHUah2cd foAm1WIZ4accqq/NsCgnqIjHDNXOnldBbOC4aPxpHB9VWuP2sPdk/y9vYo4onA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763917930; h=from:from: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=BqloJ5nFij50xG/TLfgHXhJrTMOiagUiEji4EyQKC+A=; b=NvccqiR8IurnAUiZieEOsA/hPOIiF9l6QQQsOU69fC49o6j982oXe99RLkprn4kwCIYw7h Fb0HS9CfDN2lBZJ/uT/xKbWYwMJpolTlHI66029/vAieiTBsPUCi1ympyAEkshL03n8swk /d7lq2y+g6S3VSZrbqjJ7L1iIXubbF35XsqQJ9sGOjW5kSGds8uoykIFrd4TWukPvKwu7R 3DgEMcjVjgfPKFhFem4h/EmmtmI15quyXp9Wngj5DDvJXa9t1KT9OG9udt0Fn56mdryDDR BB2BcQmbmVY9K90Cxha02tmbqT+gawGOTGE0CzsW5mimxzMxr4n+QGSpQIl28w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763917930; a=rsa-sha256; cv=none; b=BB9SoFIRqULwfdChbg0JGge2ups0okFoez59LQWgMw/hcsLH63gOgKXENKNd3RATgsFEmS gJaTTZtyIdmAxLifJZIq1iAoUx+c+1Ucm13csL4EXA8yU1n/3OVe0CJpGiuLtO1FT1DSYX kWY4CW5H87RBRlaDx9XuBbvW0lQa/ENVG4DPZkx3AgnSQbmymrUyvvfzN8yb70eS01FW6j fgYKsqbd2qzSngNAH0i2UzMc4VAx/5a1vHuirJgmIVxX7Aft/ddZFs31EZyrtL5OOMTof9 lk+Rb9YhKaH323NXmInHCKAxB6qyfV+ESbgLYVeXxFriU4985cVW7LOU7ZxBAA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (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 did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dDwVf1lnYz8gt; Sun, 23 Nov 2025 17:12:10 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id DC8118DE91; Sun, 23 Nov 2025 18:12:08 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: polyduekes@proton.me Cc: Lexi Winter , freebsd-current@freebsd.org, bapt@freebsd.org Subject: Re: changing from pkgbase to regularbase In-Reply-To: (polyduekes@proton.me's message of "Sun, 23 Nov 2025 08:07:35 +0000") References: <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com> <20251122180931.52c1141475f5faec4fad633c@dec.sakura.ne.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 23 Nov 2025 18:12:08 +0100 Message-ID: <861pload1z.fsf@ltc.des.dev> 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=utf-8 Content-Transfer-Encoding: quoted-printable polyduekes@proton.me writes: > what is the correct way to depkgbasify? There is no =E2=80=9Ccorrect=E2=80=9D way. Here's what I would suggest: 1. Make sure your system is up-to-date and consistent and you have a matching source tree installed: # pkg upgrade -y # pkg install -y FreeBSD-set-src # pkg autoremove -y 2. Make a list of non-pkgbase non-automatic packages: # pkg query -e '%a =3D=3D 0 && %o !~ base/*' %n >packages 3. Delete your installed package database: # rm /var/db/pkg/local.sqlite 4. Reinstall non-pkgbase packages: # pkg install -fy $(cat packages) This will of course also reinstall all dependencies, but we are deliberately only specifying non-automatic packages so the end result is the same as what we started out with. If we had made a list of _all_ installed packages, we would end up with everything now being marked non-automatic, and `pkg autoremove` would no longer work properly. 5. Populate /var/db/etcupdate so it will work when you later upgrade from source: # etcupdate extract 6. Optional but recommended =E2=80=94 disable the pkgbase repository: # rm /usr/local/etc/pkg/repos/FreeBSD.conf (this file will have been created by the installer and should contain a single line that enables the FreeBSD-base repository; without it, the repository remains defined in /etc/pkg/FreeBSD.conf but disabled) You can also remove cached information about the repository, which you will no longer need: # rm -rf /var/db/pkg/repos/FreeBSD-base At this point you can replace /usr/src with a git clone and upgrade as usual (`make -C /usr/src -j1.5 world kernel && etcupdate -B`). There is a shortcut for steps 2-4. I think it is both sufficient and safe, but I don't know pkg's internals well enough to say for sure; perhaps bapt@ can weight in. First you need to install the sqlite3 cli: # pkg install -Ay sqlite3 You can then use it to remove information about base packages from the package database, leaving the rest intact so you don't have to reinstall them: # sqlite3 /var/db/pkg/local.sqlite \ "delete from packages where origin like 'base/%';" If you choose this route you can also drop the autoremove in step 1, which I only put in to shorten steps 2 and 4. You still have to perform step 5 (and optionally 6). DES -- Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Sun Nov 23 20:56:27 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 4dF1TZ4RSMz6HQ3p; Sun, 23 Nov 2025 20:56:34 +0000 (UTC) (envelope-from snow@teardrop.org) Received: from hoopy.teardrop.org (hoopy.teardrop.org [52.27.92.245]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dF1TY68Qpz3g2K; Sun, 23 Nov 2025 20:56:33 +0000 (UTC) (envelope-from snow@teardrop.org) Authentication-Results: mx1.freebsd.org; none Received: by hoopy.teardrop.org (Postfix, from userid 1002) id 29E21C3AD9; Sun, 23 Nov 2025 20:56:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=teardrop.org; s=hoopy; t=1763931387; bh=j0xAw4jgfKWua7KYYB2KA+gqNTYiO94YGna+3pNAWr4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KNV3ZH9KkOTemXb1IEvrVuyJAELBOuAiEw+WtvVEPXID3KvkEbWMoo2f7XA4XsBEp nkE/lht+VktFuKO8n2w65wMwx+wxL0vkGmBRSip0usbSz48U7PhI4V6WP0y9Ytw4by Sz+fJFPrQQ+ptTpXhVeYOVUKKFuWcLueQ2y9splY= Date: Sun, 23 Nov 2025 20:56:27 +0000 From: James Snow To: Adrian Chadd Cc: FreeBSD Net , freebsd-current Subject: Re: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver Message-ID: References: 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: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:52.24.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dF1TY68Qpz3g2K Happily chugging along at just under 1Gbps - line rate here. If there's additional diag output needed, let me know. 15.0-RC2: rge0: port 0x1000-0x10ff mem 0x90c00000-0x90c0ffff,0x90c10000-0x90c13fff at device 0.0 on pci27 dev.rge.0.mac_stats.rge_rx_ok_brd: 6904850 dev.rge.0.mac_stats.rge_rx_ok_phy: 82131564 dev.rge.0.mac_stats.rge_tx_er: 1 dev.rge.0.mac_stats.rge_rx_ok: 89085257 dev.rge.0.mac_stats.rge_tx_ok: 41969076 dev.rge.0.drv_stats.rx_offload_csum_udp_valid: 1842 dev.rge.0.drv_stats.rx_offload_csum_udp_exists: 1842 dev.rge.0.drv_stats.rx_offload_csum_tcp_valid: 11223151 dev.rge.0.drv_stats.rx_offload_csum_tcp_exists: 11223151 dev.rge.0.drv_stats.rx_offload_csum_ipv4_valid: 11225027 dev.rge.0.drv_stats.rx_offload_csum_ipv4_exists: 11225027 dev.rge.0.drv_stats.rx_jumbo_frag: 0 dev.rge.0.drv_stats.rx_offload_vlan_tag: 0 dev.rge.0.drv_stats.rx_ether_csum_err: 0 dev.rge.0.drv_stats.tx_offload_vlan_tag_set: 0 dev.rge.0.drv_stats.tx_offload_udp_csum_set: 872 dev.rge.0.drv_stats.tx_offload_tcp_csum_set: 5734461 dev.rge.0.drv_stats.tx_offload_ip_csum_set: 5735351 dev.rge.0.drv_stats.tx_encap_err_toofrag: 0 dev.rge.0.drv_stats.tx_encap_refrag_cnt: 0 dev.rge.0.drv_stats.tx_encap_cnt: 5735359 dev.rge.0.drv_stats.tx_watchdog_timeout_cnt: 0 dev.rge.0.drv_stats.rx_desc_err_multidesc: 0 dev.rge.0.drv_stats.recv_input_cnt: 11226705 dev.rge.0.drv_stats.tx_task_cnt: 6785736 dev.rge.0.drv_stats.link_state_change_cnt: 2 dev.rge.0.drv_stats.txeof_cnt: 1413847 dev.rge.0.drv_stats.rxeof_cnt: 1413847 dev.rge.0.drv_stats.intr_system_errcnt: 0 dev.rge.0.drv_stats.intr_cnt: 1408789 dev.rge.0.drv_stats.transmit_queued_cnt: 5735363 dev.rge.0.drv_stats.transmit_full_cnt: 0 dev.rge.0.drv_stats.transmit_stopped_cnt: 0 dev.rge.0.drv_stats.transmit_call_cnt: 5735359 dev.rge.0.debug: 0 dev.rge.0.%iommu: rid=0x6500 dev.rge.0.%parent: pci27 dev.rge.0.%pnpinfo: vendor=0x10ec device=0x8125 subvendor=0x1458 subdevice=0xe000 class=0x020000 dev.rge.0.%location: slot=0 function=0 dbsf=pci0:101:0:0 dev.rge.0.%driver: rge dev.rge.0.%desc: RTL8125 -Snow On Sat, Nov 22, 2025 at 06:16:28PM -0800, Adrian Chadd wrote: > hi! > > i've ported Kevin Lo's openbsd driver for these realtek chipsets to FreeBSD. > It works well enough for me to use on my laptop w/ RTL8125B / Killer E3000. > I'm now opening it up to others who are willing to build/run a kernel > module to test the driver out and report back. > > The driver source is at https://github.com/erikarn/if_rge_freebsd/ along > with build instructions. > > Please note that I'm only running this on -HEAD and I plan on landing it on > -HEAD before /maybe/ backporting it to stable/15 after the 15.0 release. > I've no idea if it compiles or runs on stable/15 or the 15.0 pre-release > images. If you're willing to give it a whirl then please do and report back > but I'm unlikely to add explicit earlier source tree support in this > repository (as again I'm going to land it in -HEAD.) > > Thanks! > > > -adrian