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

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

> 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 . . .)
> 

I've tried having aarch64 do buildworld buildkernel
targeting armv7 with the system set up to act as
if there was a similar amount of RAM, increased some
for the 64-bit code using more. (Unchanged did far
more extensive thrashing in the swap space, making it
not as analogous to armv7 native.)

Example is for 4 GiByte RAM + 14 GiByte SWAP:
(hw.physmem= used in /boot/loader.conf .)

3262Mi   MaxObsActive
890248Ki MaxObsWired
3992Mi   MaxObs(Act+Wir+Lndry)
2080Mi   MaxObsSwapUsed
5241Mi   MaxObs(Act+Lndry+SwapUsed)
5981Mi   MaxObs(A+Wir+L+SU) [at such a time: 5991Mi (A+W+L+SU+InAct)]
(Various abbreviations after first reference.)

All such attempts so far have not had any failures,
so the above figures are for a completed build, not
a partial one.

It may be that the jemalloc issue is somehow specific
to the armv7.


===
Mark Millard
marklmi at yahoo.com