RE: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Sun, 12 Oct 2025 14:31:15 UTC :

> I'm still getting buildworld stoppages on armv7, with reports of 
> 
> <jemalloc>: /usr/src/contrib/jemalloc/include/jemalloc/internal/ehooks.h:170: Failed assertion: "p[i] == 0"
> 
> seemingly at random, but only while building libraries. If buildworld is 
> restarted, it picks up where it left off using meta mode and gets somewhat 
> farther along before stopping again. Eventually it finishes.

What is median (or mean or just some variation on typical) for how
many restarts are involved to get the overall build to finish?

This would help judge how many rebuilds would reasonably indicate
that the problem is not repeating in a test context.

> At least
> one buildworld ran to completion without stopping, but that's the exception.
> 
> The machine is a Pi2 v1.1, USB mechanical hard disk, headless with
> serial console and ssh access.

What would the information be for someone to
closely replicate your build attempts?

/etc/src-env.conf content?
/etc/src.conf     content?
/etc/make.conf    content?
Any other tailoring?
What commands used to set up and start the build attempts?

> Uname -a reports
> FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #5 main-n281033-033587a985a4: Fri Oct 10 02:10:37 PDT 2025 [email protected]:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
> 
> Uname -KU reports
> 1600001 1600001
> 
> Any suggestions?

One form of experiment would be to have a media set up
with just an official 16.0-CURRENT snapshot installed,
with the matching /usr/src/ installed, and attempt to
have that snapshot rebuild itself in the reproducible
build mode one or more times. A point would be to keep
the configuration changes to a near minimum for the
goal of reproducing the snapshot's original build.

(Part of this would be making any build after finishing
an overall build sequence start from scratch instead of
having WITH_META_MODE apply at that point.)

Replication via such would avoid all your environment
specifics, other than the specific hardware you use.
It would be something others could do the same for on
the hardware they have.

I pick an official snapshot over an official pkgbase
distribution here because:

) It is traceable to a specific /usr/src/ commit for
   everything ( not just /usr/src/sys/ ). (pkgbase
   does not do this up-front traceability that can
   be referenced or used later for CURRENT or for
   STABLE for world.)

) While pkgbase provides various kernels, it only
   provides one world build for CURRENT or STABLE
   and its world build options are not obvious and
   might not be correct for the purpose.

(Note: I'm fond of using pkgbase and official
distributions of pkgbase builds are the basis of my
environments these days, but official pkgbase
distributions do have tradeoffs for some types of
activity, especially for CURRENT and STABLE. I
normally use CURRENT. At some point I will restart
also having personal kernel and world builds that I
can use, in addition to using official pkgbase
distributions as the basis for my environments.)

> The serial console emits no recognizable complaints/warnings.
> At this point it's unclear if the trouble is upstream, local or hardware.
> Apart from this one failure mode the machine, one of three exhibiting the same
> behavior, seems stable.


Having 3 systems that do the same thing would suggest that
hardware failure is not the likely cause, at least for the
independent hardware involved. Do the 3 systems have
independent devices? Or is some hardware common across
the 3 systems when the builds are being done?

Do you have any RPi2B v1.1's (on which you do such builds)
that do not show the behavior?

Do you have any armv7 systems other than RPi2B v1.1's? If
yes, do any such show the failure?

Do you know what version of FreeBSD was running the first
time that you got such a failure? How about what was
running for the build before that? (It may be that small
enough builds would not be relevant.) Note: I ask but I'm
not expecting that you will happen to know.


===
Mark Millard
marklmi at yahoo.com