Date: Thu, 13 Nov 2025 23:16:56 -0800 From: Carl Shapiro <cshapiro@panix.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Ronald Klop <ronald@freebsd.org>, freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: <877bvthymv.fsf@panix.com> In-Reply-To: <aRXuLTN4hkGykHIl@www.zefox.net> (bob prohaska's message of "Thu, 13 Nov 2025 06:41:49 -0800") References: <aOu7s9roGCofdCOw@www.zefox.net> <aOvTG-20QRJtJJwf@int21h> <CANCZdfrJ8rph_rkT3Mk-sNYKNspoV15SvHWLsahzS0HnULi4ww@mail.gmail.com> <aO068RrAehdiHOoZ@www.zefox.net> <aRUJPryA4Vmu8dDD@www.zefox.net> <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <aRXuLTN4hkGykHIl@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
bob prohaska <fbsd@www.zefox.net> writes: > All the assertion failures I've seen have been in the clang libraries during > buildworld. They appear to happen in a variety of cases, indicated by the > different .sh and .cpp filenames found in the files under > http://www.zefox.net/~fbsd/assertion_failure/ Do you have the stdout and stderr of the build somewhere in there as well? The make(1) invocation in the readme file shows its output being redirected to a file. The assert you mentioned in the subject of your e-mail message, which I also saw in the readme file, could come from jemalloc. See these lines of code for the context https://github.com/facebook/jemalloc/blob/dev/src/extent.c#L805-L814 That assertion will be tripped when jemalloc sees non-zero memory that it expects to be zeroed. See for example https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L55-L106 Looking at the code, my hypothesis would be that jemalloc thinks it's committing memory for the first time but the memory is coming back with non-zero data. Just curious, but is over-commit enabled on your system? Here is the signal jemalloc is using to check https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L729-L737 > The failures are random in the sense that restarting buildworld either > produces a new assertion failure in a different library or completion. > > It isn't obvious how to capture a stack trace, if you can provide guidance > I'll give it a try. As is, buildworld simply stops, the machine does not > crash. It might be captured for you already? I noticed files with names containing "symbolizer-input" and "symbolizer-ouput" like this one http://www.zefox.net/~fbsd/assertion_failure/hostname_pelorus.zefox.org/symbolizer-output-7282d9 and the output files contain a stack trace like this llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:731:7 llvm::sys::RunSignalHandlers() /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:0:5 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 Any idea who or what is creating those files and when?home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?877bvthymv.fsf>