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--