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

On Fri, Nov 14, 2025 at 05:04:10PM -0500, Carl Shapiro wrote:
> bob prohaska <[email protected]> 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