From nobody Fri Nov 14 22:04:10 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 4d7WPn0Z1tz6GSyw; Fri, 14 Nov 2025 22:04:13 +0000 (UTC) (envelope-from cshapiro@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (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 4d7WPm1W7Dz3Ybg; Fri, 14 Nov 2025 22:04:12 +0000 (UTC) (envelope-from cshapiro@panix.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=FxJwDIYI; dmarc=pass (policy=none) header.from=panix.com; spf=pass (mx1.freebsd.org: domain of cshapiro@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=cshapiro@panix.com Received: from panix3.panix.com (panix3.panix.com [166.84.1.3]) by mailbackend.panix.com (Postfix) with ESMTPS id 4d7WPl2Xrwz49JV; Fri, 14 Nov 2025 17:04:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1763157851; bh=PFyHd4VGumRfkhudOXdpZL1Au86adSjsEaiCTYaGa5I=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=FxJwDIYI0rU/zA4pS+o1hV0cLrHvCkZfuduBuRuqkczGhdSyLjbrK6jM+jfqdVqv5 dWjOwnN3WFxCEMDqpkDdP0dwryKyBj9UCAn0XqigFDx6nBITW9fGY/5vg7AhHHlfSj sAzDbTjmPbht0J5B1vCnNg36aS5pYKJ9yGEsBv+8= From: Carl Shapiro To: bob prohaska Cc: Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld In-Reply-To: (bob prohaska's message of "Fri, 14 Nov 2025 07:25:27 -0800") References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> Date: Fri, 14 Nov 2025 17:04:10 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) 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 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.60 / 15.00]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; URIBL_RED(0.50)[zefox.net:email]; BAD_REP_POLICIES(0.10)[]; HAS_ANON_DOMAIN(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[166.84.1.89:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[166.84.1.89:from]; DMARC_POLICY_ALLOW(0.00)[panix.com,none]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_TLS_ALL(0.00)[]; R_DKIM_ALLOW(0.00)[panix.com:s=panix]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:166.84.1.64/26]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4d7WPm1W7Dz3Ybg 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.