Re: Tracing NetBSD sun4v issues

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Fri, 9 Oct 2026 14:59:45 +0100
Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:

> The backtrace suggests it died in jemalloc but it was nowhere near this
> code as indicated by my debug printf() statements. Two questions bug me:

I managed to trace the full call chain and I think it does crash in
jemalloc:

(gdb) bt
#0  ecache_alloc_grow (tsdn=0x40216050, pac=0x40a03a00, ehooks=0x40a00100, ecache=0x40a0cf28, expand_edata=0x0, size=24576, alignment=8192, zero=false, guarded=false) at /usr/src/external/bsd/jemalloc/lib/../dist/src/extent.c:97
#1  0x000000004057c26c in pac_alloc_real (tsdn=0x40216050, pac=0x40a03a00, ehooks=0x40a00100, size=24576, alignment=8192, zero=<optimized out>, guarded=<optimized out>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/pac.c:124
#2  0x000000004057c3fc in pac_alloc_real (guarded=false, zero=false, alignment=8192, size=24576, ehooks=0x40a00100, pac=0x40a03a00, tsdn=0x40216050) at /usr/src/external/bsd/jemalloc/lib/../dist/src/pac.c:119
#3  pac_alloc_impl (tsdn=0x40216050, self=0x40a03a00, size=24576, alignment=8192, zero=<optimized out>, guarded=<optimized out>, frequent_reuse=<optimized out>, deferred_work_generated=<optimized out>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/pac.c:178
#4  0x000000004057db7c in pai_alloc (deferred_work_generated=0xffffffffffffc2bf, frequent_reuse=true, guarded=false, zero=<optimized out>, alignment=8192, size=24576, self=0x40a03a00, tsdn=0x40216050) at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/pai.h:43
#5  pa_alloc (tsdn=0x40216050, shard=0x40a039e8, size=24576, alignment=8192, slab=<optimized out>, szind=<optimized out>, zero=<optimized out>, guarded=<optimized out>, deferred_work_generated=<optimized out>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/pa.c:139
#6  0x00000000405b78b8 in arena_slab_alloc (tsdn=0x40216050, arena=0x40a01100, binind=<optimized out>, binshard=<optimized out>, bin_info=0x40828470 <je_bin_infos+1584>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/arena.c:839
#7  0x00000000405b8d24 in arena_cache_bin_fill_small (tsdn=<optimized out>, arena=<optimized out>, cache_bin=<optimized out>, cache_bin_info=<optimized out>, binind=<optimized out>, nfill=<optimized out>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/arena.c:1034
#8  0x000000004056e374 in je_tcache_alloc_small_hard (tsdn=0x40216050, arena=0x40a01100, tcache=<optimized out>, cache_bin=0x40216578, binind=<optimized out>, tcache_success=0xffffffffffffc568) at /usr/src/external/bsd/jemalloc/lib/../dist/src/tcache.c:238
#9  0x00000000405c80e0 in tcache_alloc_small (slow_path=<optimized out>, zero=true, binind=<optimized out>, size=<optimized out>, tcache=0x402163c0, arena=<optimized out>, tsd=0x40216050) at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/tcache_inlines.h:68
#10 arena_malloc (slow_path=<optimized out>, tcache=0x402163c0, zero=true, ind=<optimized out>, size=<optimized out>, arena=0x0, tsdn=0x40216050) at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/arena_inlines_b.h:151
#11 iallocztm (slow_path=<optimized out>, arena=0x0, is_internal=false, tcache=0x402163c0, zero=true, ind=<optimized out>, size=<optimized out>, tsdn=0x40216050) at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/jemalloc_internal_inlines_c.h:55
#12 imalloc_no_sample (ind=<optimized out>, usize=768, size=<optimized out>, tsd=0x40216050, dopts=<synthetic pointer>, sopts=<synthetic pointer>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2425
#13 imalloc_body (tsd=0x40216050, dopts=<synthetic pointer>, sopts=<synthetic pointer>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2600
#14 imalloc (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2714
#15 calloc (num=<optimized out>, size=<optimized out>) at /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2879
#16 0x0000000040690028 in __hash_open (file=0x406cd2b0 "/etc/spwd.db", flags=<optimized out>, mode=<optimized out>, info=0x0, dflags=<optimized out>) at /usr/src/lib/libc/db/hash/hash.c:111
#17 0x000000004065e664 in _pw_opendb (db=0x4093d2c0 <_compat_state+8>, version=0x4093d72c <_compat_state+1140>) at /usr/src/lib/libc/gen/getpwent.c:196
#18 0x000000004065e7a4 in _compat_start (state=0x4093d2b8 <_compat_state>) at /usr/src/lib/libc/gen/getpwent.c:1706
#19 0x00000000406609b0 in _compat_setpassent (nsrv=0x0, nscb=0x0, ap=0xffffffffffffcc18) at /usr/src/lib/libc/gen/getpwent.c:2206
#20 0x000000004062ecc8 in _nsdispatch (retval=0x0, disp_tab=0x4080ca60 <dtab>, database=0x406cd318 "passwd", method=0x406cd350 "setpassent", defaults=0x4080b7d8 <__nsdefaultcompat_forceall>) at /usr/src/lib/libc/net/nsdispatch.c:670
#21 0x0000000040661cc8 in _setpassent (stayopen=<optimized out>) at /usr/src/lib/libc/gen/getpwent.c:2583
#22 0x0000000000100bc0 in fn (name=0x100e30 "root", uid=0xffffffffffffd564) at test.c:29
#23 0x0000000000100c48 in main () at test.c:55


This is the reported location:

Core was generated by `test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000040589790 in ecache_alloc_grow (tsdn=0x40589784 <ecache_alloc_grow+804>, pac=0x3fff, 
    ehooks=0xffffffffffffb881, ecache=<optimized out>, expand_edata=<optimized out>, size=18446744073709536208, 
    alignment=<optimized out>, zero=<optimized out>, guarded=<optimized out>)
    at /usr/src/external/bsd/jemalloc/lib/../dist/src/extent.c:126

And looking at the registers, value in %fp looks to be truncated in the
upper 32 bits. It should be similar to the value in %sp:

(gdb) info reg
g0             0x0                 0
g1             0xdfb               3579
g2             0x0                 0
g3             0x0                 0
g4             0x0                 0
g5             0xe8000000000000    65302194596872192
g6             0x206e69730a        139291357962
g7             0x40216ac0          1075931840
o0             0x40a17e80          1084325504
o1             0x40a03a00          1084242432
o2             0x0                 0
o3             0xffffbc00          4294949888
o4             0x2000              8192
o5             0x0                 0
sp             0xffffffffffffb7d1  0xffffffffffffb7d1
o7             0x40589784          1079547780
l0             0xe030              57392
l1             0x40a11a00          1084299776
l2             0x0                 0
l3             0x40827d54          1082293588
l4             0x0                 0
l5             0x40a0cf28          1084280616
l6             0x40a00100          1084227840
l7             0x0                 0
i0             0x6000              24576
i1             0x3fff              16383
i2             0xffffffffffffb881  -18303
i3             0x40589784          1079547780
i4             0x8                 8
i5             0xffffffffffffc3d0  -15408
fp             0xffffc4b8          0xffffc4b8
i7             0x40208000          1075871744
pc             0x40589790          0x40589790 <ecache_alloc_grow+816>
npc            0x40208008          0x40208008
state          0x4482000200        294238814720
fsr            0x0                 [ ]
fprs           <unavailable>
y              0x0                 0
cwp            0x0                 0
pstate         0x2                 [ IE ]
asi            0x82                130
ccr            0x44                [ icc.z xcc.z ]

So what we need to find out is exactly why the frame pointer value gets
corrupted.