port-sparc64/46274: sparc64 running netbsd 32bit code causes a lot of cores

[martin%NetBSD.org@localhost]

>Number:         46274
>Category:       port-sparc64
>Synopsis:       sparc64 running netbsd 32bit code causes a lot of cores
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 28 14:15:00 +0000 2012
>Originator:     Martin Husemann
>Release:        NetBSD 6.99.4
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD thirdstage.duskware.de 6.99.4 NetBSD 6.99.4 (MODULAR) #20: Mon 
Mar 26 12:42:40 CEST 2012 
martin%night-porter.duskware.de@localhost:/usr/src/sys/arch/sparc64/compile/MODULAR
 sparc64
Architecture: sparc64
Machine: sparc64
>Description:

When doing a chroot to a sparc install on sparc64-current many programs
die unexpectedly.

An example backtrace (though they seem to slightly differ):

#0  0x40155fa8 in __libc_thr_getspecific_stub (k=0)
    at /usr/src/lib/libc/thread-stub/thread-stub.c:321
#1  0x401dcd98 in choose_arena () at /usr/src/lib/libc/stdlib/jemalloc.c:1573
#2  imalloc (size=508) at /usr/src/lib/libc/stdlib/jemalloc.c:2988
#3  0x401dce14 in malloc (size=508)
    at /usr/src/lib/libc/stdlib/jemalloc.c:3702
#4  0x0001fda0 in ckmalloc ()
#5  0x0001fe74 in stalloc ()
#6  0x000200a0 in growstackblock ()
#7  0x00015e34 in padvance ()
#8  0x00016014 in shellexec ()
#9  0x00014f10 in evalcommand ()
#10 0x000141e4 in evaltree ()
#11 0x0001f6d0 in cmdloop ()
#12 0x0001f954 in main ()

The crash is here:
   0x40155f84 <__libc_thr_getspecific_stub>:    save  %sp, -96, %sp
   0x40155f88 <__libc_thr_getspecific_stub+4>:  sethi  %hi(0xfffff000), %g1
   0x40155f8c <__libc_thr_getspecific_stub+8>:  add  %i0, %i0, %g2
   0x40155f90 <__libc_thr_getspecific_stub+12>: add  %g2, %i0, %g2
   0x40155f94 <__libc_thr_getspecific_stub+16>: or  %g1, 0xbc, %g1
   0x40155f98 <__libc_thr_getspecific_stub+20>: sethi  %hi(0x113000), %l7
   0x40155f9c <__libc_thr_getspecific_stub+24>: 
    call  0x40150ca8 <__sparc_get_pc_thunk.l7>
   0x40155fa0 <__libc_thr_getspecific_stub+28>: 
    add  %l7, 0x204, %l7        ! 0x113204
   0x40155fa4 <__libc_thr_getspecific_stub+32>: sll  %g2, 2, %g2
=> 0x40155fa8 <__libc_thr_getspecific_stub+36>: ld  [ %l7 + %g1 ], %g1
   0x40155fac <__libc_thr_getspecific_stub+40>: ld  [ %g1 + %g2 ], %i0
   0x40155fb0 <__libc_thr_getspecific_stub+44>: ret 
   0x40155fb4 <__libc_thr_getspecific_stub+48>: restore 
   0x40155fb8 <__libc_thr_keydelete_stub>:      save  %sp, -96, %sp
   0x40155fbc <__libc_thr_keydelete_stub+4>:    sethi  %hi(0xfffff000), %g1
   0x40155fc0 <__libc_thr_keydelete_stub+8>:    add  %i0, %i0, %g2

g1             0xfffff0bc       -3908
g2             0x0              0
l7             0x402691a0       1076269472

This all looks sane and very similar to the values we get when running the
same code with a 32bit kernel (which works just fine).

>How-To-Repeat:

   mount $(sparc-disk) /mnt
   chroot /mnt /bin/sh
   cd usr/tests
   atf-run | atf-report

This will stop right away with sh.core files from the shell trying to set
up the atf pipeline.

>Fix:
n/a