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
