On 16.11.2025 18:51, Warner Losh wrote:
Maybe try main with the following patch. Adrian noticed the TLS
mismatch. I don't think it will matter, but TLS thread model stuff
always gives me a big headache. If the following fails to apply, just
copy the JEMALLOC_TLS_MODEL line from i386 to arm. The default changed
elsewhere, but this wasn't updated here.
Warner
Unfortunately, that doesn't help. I'm out of ideas on how to debug this,
all of my attempts have failed.
The problem only occurs when Clang compiles a larger project and is
intermediate. Attempt to compile the clang generated reproducer is
always successful.
It's clear that the parallelism introduced by make plays a significant
role. But the system never reached an OOM condition before failure.
I would be grateful for any help and ideas on what to do next.
Michal
diff --git a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/
jemalloc_FreeBSD.h b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/
jemalloc_FreeBSD.h
index 34c86271ab2e..bd6850ebd95f 100644
--- a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
+++ b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
@@ -26,10 +26,11 @@
#undef LG_SIZEOF_LONG
#undef LG_SIZEOF_INTMAX_T
+#define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec")))
+
#ifdef __i386__
# define LG_VADDR 32
# define LG_SIZEOF_PTR 2
-# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec")))
#endif
#ifdef __ia64__
# define LG_VADDR 64
@@ -38,7 +39,6 @@
#ifdef __sparc64__
# define LG_VADDR 64
# define LG_SIZEOF_PTR 3
-# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec")))
#endif
#ifdef __amd64__
#ifdef _USE_LG_VADDR_WIDE
@@ -47,7 +47,6 @@
# define LG_VADDR 48
#endif
# define LG_SIZEOF_PTR 3
-# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec")))
#endif
#ifdef __arm__
# define LG_VADDR 32
@@ -69,11 +68,9 @@
#ifdef __powerpc64__
# define LG_VADDR 64
# define LG_SIZEOF_PTR 3
-# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec")))
#elif defined(__powerpc__)
# define LG_VADDR 32
# define LG_SIZEOF_PTR 2
-# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec")))
#endif
#ifdef __riscv
# define LG_VADDR 48
On Sun, Nov 16, 2025, 8:42 AM bob prohaska <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Nov 15, 2025 at 04:08:50PM -0700, Warner Losh wrote:
> On Fri, Nov 14, 2025 at 12:31 AM Herbert J. Skuhra
<[email protected] <mailto:[email protected]>>
> wrote:
>
> > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote:
> > >
> > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote:
> > > > Op 12-11-2025 om 23:25 schreef bob prohaska:
> > > > > For lack of any better ideas I've collected some of the
assertion
> > failure
> > > > > /tmp files by host at
> > > > > http://www.zefox.net/~fbsd/assertion_failure/ <http://
www.zefox.net/~fbsd/assertion_failure/>
> > > > >
> > > > > Thanks for reading,
> > > > >
> > > > > bob prohaska
> > > > >
> > > > >
> > > >
> > > > A really uneducated guess, but might the update of jemalloc
[1] have
> > introduced some subtle issues on armv7?
> > > > You can try reverting:
> > https://cgit.freebsd.org/src/commit/?
id=c43cad87172039ccf38172129c79755ea79e6102 <https://
cgit.freebsd.org/src/commit/?
id=c43cad87172039ccf38172129c79755ea79e6102>
> > .
> > > >
> > > What is the required syntax? Trying a simple
> > >
> > > root@generic:/usr/src # git revert -m 1
> > c43cad87172039ccf38172129c79755ea79e
> > > generated a torrent of conflict reports
> > > The source tree is expendable with no valued customizations.
> >
> > Try:
> >
> > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8
> > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353
> > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102
> >
>
> Do you have to do all three? I'd have thought only the first one
would be
> needed.
Necessary or not, it seems to have worked. No errors were reported and
buildworld/kernel has run successfully on two of three Pi2's. One of
them has rebooted and run an incremental buildworld using its new kernel
and world.
Next step is to run make cleandir twice on that machine and try a
clean-start buildworld/kernel. Those results will take a few days.
In the meantime, is there any explicit test to see if the reversion
worked as expected? Searching for null (no error) results is slow.
For example, Peter Holm's stress2 suite found lots of mischief in
years gone by, might it be applied to this sort of problem?
Thanks to you and everybody else for your help!
bob prohaska
