15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4d9XhM1MzJz3mRY

On Nov 17, 2025, at 19:53, Adrian Chadd <adrian@freebsd.org> wrote:

> (random reply, sorry bob)
>=20
> 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?

I do not remember seeing such a claim about "p[i] =3D=3D 0" failures.

All examples that I'm aware of involve both parallelism and memory
pressure. Parallelism without memory pressure did not get have the
issue happen in my armv7 testing on the Windows Dev Kit 2023.
(Trying to test such on a RPi2B v1.1 would be problematical.)

Parallelism with memory pressure has not shown the problem so far
for aarch64 testing.


> 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)
>=20
>=20
> -adrian
>=20
>=20
> 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:
> >=20
> > > 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.
> >=20
> > 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.
> >=20
> > 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.
>=20
> 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.
>=20
> =
http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/buildw=
orld.log
> =
http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbol=
izer-input-bcaebf
> =
http://www.zefox.net/~fbsd/assertion_failure/hostname_www.zefox.org/symbol=
izer-output-1aa401
>=20
> 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.




=3D=3D=3D
Mark Millard
marklmi at yahoo.com