Tracing NetBSD sun4v issues

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

I'm trying to trace the root cause of NetBSD issues on sun4v. I have a
small user space test program that reliably dies with SIGSEGV. The test
involves calling setpassent() which in turn calls nsdispatch() where it
dies.

I added printf() statements to those functions to see where it dies in
nsdispatch():

int
/*ARGSUSED*/
nsdispatch(
	void *retval, const ns_dtab disp_tab[], const char *database,
	const char *method, const ns_src defaults[], ...)
{
	....

	return (result ? result : NS_NOTFOUND);
}

And it dies when executing the last return statement. The nsdispatch()
function does not appear to return to its caller because the process
dies and the next printf() debug statement after this function is not
executed.

If I copy the core file to sun4u system running the same NetBSD
release, I get strange backtraces:

ultra10$ gdb test test.core
Reading symbols from test...
[New process 112]
Core was generated by `test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000405899d0 in ecache_alloc_grow (tsdn=0x405899c4 <ecache_alloc_grow+804>, pac=0x3fff, 
    ehooks=0xffffffffffffb871, ecache=<optimized out>, expand_edata=<optimized out>, size=18446744073709536192, 
    alignment=<optimized out>, zero=<optimized out>, guarded=<optimized out>)
    at /usr/src/external/bsd/jemalloc/lib/../dist/src/extent.c:126

(gdb) bt
#0  0x00000000405899d0 in ecache_alloc_grow (tsdn=0x405899c4 <ecache_alloc_grow+804>, pac=0x3fff, 
    ehooks=0xffffffffffffb871, ecache=<optimized out>, expand_edata=<optimized out>, size=18446744073709536192, 
    alignment=<optimized out>, zero=<optimized out>, guarded=<optimized out>)
    at /usr/src/external/bsd/jemalloc/lib/../dist/src/extent.c:126
#1  0x0000000040208008 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) disas
Dump of assembler code for function ecache_alloc_grow:
   0x00000000405896a0 <+0>:     save  %sp, -304, %sp
   0x00000000405896a4 <+4>:     mov  0x37f, %l6
   0x00000000405896a8 <+8>:     ldub  [ %fp + 0x8be ], %l4
   0x00000000405896ac <+12>:    mov  1, %l5
   0x00000000405896b0 <+16>:    sllx  %l6, 6, %g1
...
   0x00000000405899c4 <+804>:   call  0x40587b80 <je_extent_alloc_wrapper>
   0x00000000405899c8 <+808>:   stx  %l4, [ %sp + 0x8af ]
   0x00000000405899cc <+812>:   ret 
=> 0x00000000405899d0 <+816>:   restore  %g0, %o0, %o0
   0x00000000405899d4 <+820>:   call  0x4057e700 <je_malloc_mutex_lock_slow>


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:

1) Why does GDB think the issues occurred in jemalloc? Does this
indicate corruption of stack frames?

2) Assuming the stack frames are corrupt, does this mean that the
disassembly of the instruction that caused SIGSEGV (restore) may also
be suspicious and likely invalid?