RETITLED: On aarch64 in a armv7 chroot, I've reproduced the armv7: jemalloc/internal/ehooks.h:170: Failed assertion: "p[i] == 0"

On Nov 14, 2025, at 14:04, Mark Millard <[email protected]> wrote:

> On Nov 14, 2025, at 13:57, Mark Millard <[email protected]> wrote:
> 
>> On Nov 10, 2025, at 17:46, bob prohaska <[email protected]> wrote:
>> 
>>> On Mon, Nov 10, 2025 at 07:02:35PM +0000, void wrote:
>>>> On Mon, Nov 10, 2025 at 07:39:51AM -0800, bob prohaska wrote:
>>>> 
>>>>> Did the machine hang entirely? If so, how did you recover control?
>>>> 
>>>> locked solid. rebooted.
>>>> 
>>>> The machine responded ok interactively until that point.
>>>> 
>>> Have you attempted a debugger escape on the serial console?
>>> Enter, tilda, control-B is the default on -current
>>> 
>>> If it works some extra information can be furnished to those
>>> trying to help. I'm not among them, but have been the beneficiary
>>> many times in the past.
>> 
>> [There is also the jemalloc assertion issue.]
>> 
>> This is just a note about how things go in
>> another context, with more cores, more RAM
>> and aarch64 handling armv7 via a chroot to
>> an armv7 world.
>> 
>> Context: Windows Dev Kit 2023, 8 cores,
>> 32 GiBytes of RAM, USB3 media. main 16
>> via an official pkgbase distribution
>> installation. swap was configured but
>> went unused: SwapUsed==0 was always
>> observed. No /etc/src*.conf .
>> 
>> # cat /etc/make.conf 
>> WRKDIRPREFIX?=/wrkdirs
>> 
>> So . . .
>> 
>> A from-scratch armv7:
>> 
>> # env WITH_META_MODE make -j8 buildworld buildkernel
> 
> Sorry, I missed the "=":
> 
> # env WITH_META_MODE= make -j8 buildworld buildkernel
> 
>> worked just fine, taking somewhat under 4 hours.
>> 6298Mi MaxObs(Act+Wired+Laundry+SwapUsed), Inact
>> started large from prior activity and stayed large.
>> ("MaxObs" is short for: Maximum Observed.)
>> 
>> So it does tend to suggest that memory pressure
>> handling contributes to at least making the
>> problems more likely to occur --and might even
>> be required.
>> 
>> 
>> Part of the reason this was tried is that jemalloc
>> is world code, not kernel code. Thus jemalloc
>> assertions need not require the armv7 kernel.
>> 
>> 
>> I can also test telling FreeBSD to use only, say,
>> 2 GiBytes of RAM and pick the 3.5 GiByte SWAP space
>> that is available, so RAM+SWAP==5.5 GiBytes, still
>> using -j8 . /boot/loader.conf :
>> 
>> hw.physmem="2G"
>> 
>> It may be that I'd need closer to 3G to avoid
>> running out of RAM+SWAP.
> 
> The build has started.
> 

I've reproduced: jemalloc/internal/ehooks.h:170: Failed assertion: "p[i] == 0"

Building /usr/obj/usr/src/arm.armv7/lib/clang/libllvm/MC/MCDXContainerStreamer.pico
<jemalloc>: /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed assertion: "p[i] == 0"
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.

Unfortunately, no *.core file was produced. Also the
printed backtrace only makes it to:

#4 0x29d4c418 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3

instead reaching where jemalloc was on the call stack.

Also, by themselves:

# ls -lodTt /tmp/*
-rw-r--r--  1 root wheel -     9212 Nov 14 15:01:22 2025 /tmp/LTO-7733f5.sh
-rw-r--r--  1 root wheel - 15091442 Nov 14 15:01:22 2025 /tmp/LTO-7733f5.cpp

do not reproduce the problem via:

# cd /tmp/
# . /tmp/LTO-7733f5.sh
# 

The more active overall system activity is
apparently required. (Not surprising, given
other things Bob P. has reported.)

For reference, some Maximum Observed figures,
looked at after the failure, were:

1499Mi   MaxObsActive
527800Ki MaxObsWired
1991Mi   MaxObs(Act+Wir+Lndry)
858584Ki MaxObsSwapUsed
2219Mi   MaxObs(Act+Lndry+SwapUsed)
2692Mi   MaxObs(A+W+L+SU) [at such a time: 2699Mi (A+W+L+SU+InAct)]
(Various abbreviations after first reference.)

So: 2048 MiBytes < MaxObs(Act+Wir+Lndry+SwapUsed) < RAM+SWAP == 5632 MiBytes 
was sufficient to have the problem occur.


So I've still no evidence of which path to the
assert is involved. But we do know that the
armv7 kernel is not required for the problem
to occur. (No surprise, but still . . .)


===
Mark Millard
marklmi at yahoo.com