On 13.11.2025 10:52, Ronald Klop wrote:
Op 13-11-2025 om 10:07 schreef Carl Shapiro:
Ronald Klop <[email protected]> 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