Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld

From: Adrian Chadd <adrian_at_freebsd.org>
Date: Tue, 18 Nov 2025 03:53:15 UTC
(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 <fbsd@www.zefox.net> wrote:

> On Fri, Nov 14, 2025 at 05:04:10PM -0500, Carl Shapiro wrote:
> > bob prohaska <fbsd@www.zefox.net> 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
>
>
>