Re: openjdk11 compile fail on armv7 - (Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld)

In reply to: Ronald Klop : "openjdk11 compile fail on armv7 - (Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld)"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Fri, 14 Nov 2025 13:15:52 UTC
On Nov 14, 2025, at 04:50, Ronald Klop <ronald-lists@klop.ws> wrote:

> Van: Michal Meloun <mmel@FreeBSD.org>
> Datum: donderdag, 13 november 2025 11:38
> Aan: Ronald Klop <ronald@FreeBSD.org>, Carl Shapiro <cshapiro@panix.com>
> CC: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org, freebsd-current@freebsd.org
> Onderwerp: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld
> 
> 
> On 13.11.2025 10:52, Ronald Klop wrote:
> > Op 13-11-2025 om 10:07 schreef Carl Shapiro:
> >> Ronald Klop <ronald@FreeBSD.org> writes:
> >>
> >>> My thought was triggered by this as a build of opendjk11 failed with a
> >>> jemalloc error.
> >>> https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025- >>> September/804963.html
> >>
> >> Is this build failure very reproducible?  Is there more of a stack trace
> >> to go with it?
> >>
> >> When the jemalloc witness code observes a locking error the process
> >> should abort immediately with a SIGABRT.  However, there is SIGBUS
> >> reported in the build output prior to the witness error which makes it
> >> look like OpenJDK may have been handling a signal while the witness code
> >> was running.  If malloc is somehow being called from a signal handler
> >> that is asking for trouble.
> >>
> >> Here's a closed issue from the old jemalloc repository about a witness
> >> error when malloc was called from a signal handler
> >>
> >> https://github.com/jemalloc/jemalloc/issues/1224
> >
> >
> > Hi,
> >
> > I only have this example. I don't run armv7 myself.
> > Unfortunately the armv7 pkg builders don't run that often.
> >
> > This is the only failure on main-armv7, but AFAIK no new pkg build run > for main-armv7 has happened since.
> > https://portsfallout.com/fallout? > port=java%2Fopenjdk&maintainer=&env=armv7&category=&flavor=
> >
> > I just noticed that the full build log is also already gone from the pkg > build server.
> >
> > Regards,
> > Ronald.
> 
> I am also a victim of this problem. In my case, unfortunately, the problem is rare and transient. It occurs intermittently and can be resolved by restarting the make. I can confirm that the problem is not related to a specific port. I have experienced it with gdal, qt6-webengine, and rust at minimum.
> 
> 
> I'm guessing it may be related to memory pressure before OOM. Unfortunately, I'm out of ideas now...
> 
> Michal
>   
> 
> I was able to reproduce openjdk11 failure in an armv7 poudriere build on aarch64 Raspberry Pi.
> The build doesn't always fail and the output is not always the same. Here is the output of two different compile runs. [00:19:54] === Output from failing command(s) repeated here ===
> [00:19:54] * For target jdk_modules_java.base__the.java.base_batch:
> [00:19:54] #
> [00:19:54] # A fatal error has been detected by the Java Runtime Environment:
> [00:19:54] #
> [00:19:54] # SIGBUS (0xa) at pc=0x2031ce84, pid=34578, tid=124336
> [00:19:54] #
> [00:19:54] # JRE version: OpenJDK Runtime Environment (11.0.11+9) (build 11.0.11+9-1)
> [00:19:54] # Java VM: OpenJDK Server VM (11.0.11+9-1, mixed mode, g1 gc, bsd-)
> [00:19:54] # Problematic frame:
> [00:19:54] # C [libc.so.7+0x1ace84] _malloc_thread_cleanup+0xa43c
> [00:19:54] #
> [00:19:54] # Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/java.core
> [00:19:54] #
> [00:19:54] # An error report file with more information is saved as:
> [00:19:54] # /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_pid34578.log
> [00:19:54] #
> 
> 
> 
> [03:09:57] === Output from failing command(s) repeated here ===
> [03:09:57] * For target support_jmods_java.sql.jmod:
> [03:09:57] #
> [03:09:57] # A fatal error has been detected by the Java Runtime Environment:
> [03:09:57] #
> [03:09:57] # SIGBUS (0xa) at pc=0x2169d0c4, pid=16567, tid=137017
> [03:09:57] #
> [03:09:57] # JRE version: OpenJDK Runtime Environment (11.0.29+7) (build 11.0.29+7-1)
> [03:09:57] # Java VM: OpenJDK Server VM (11.0.29+7-1, mixed mode, serial gc, bsd-)
> [03:09:57] # Problematic frame:
> [03:09:57] # J 77 c2 java.io.DataInputStream.readUnsignedShort()I java.base (39 bytes) @ 0x2169d0c4 [0x2169cf40+0x00000184]
> [03:09:57] #
> [03:09:57] # Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/jmod.core
> [03:09:57] #
> [03:09:57] # An error report file with more information is saved as:
> [03:09:57] # /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_pid16567.log
> 
> 
> This is in a poudriere build that does not leave the environment behind after a failure. This weekend I can try to run poudriere with the options to keep the jail alive and gather some more artifacts for people to analyze.

There is the "poudriere bulk" is the option:

     -w       Save WRKDIR on build failure.  The WRKDIR will be tarred up into
              ${POUDRIERE_DATA}/wrkdirs.

I have a /wrkdirs/usr/ports/ that I use for creating
/wrkdirs/usr/ports/*/*/ and expanding the archive.
I do that to have the same path as seen in the
builder jail.

However, sometimes there are materials that are outside
the area tar'd ( such as the builder's /tmp/ ). So live
sessions can have required uses.

> What kind of info would be valuable? The *.core and the hs_err*.log file maybe.

===
Mark Millard
marklmi at yahoo.com