segfault in maybePerformBlockedException

[duncan]

On the 6.12 stable branch on Sparc Solaris, the buildbot reports that stage2 segfaults.

Using GDB on the core file gives us this backtrace

#0  0x02421dfc in maybePerformBlockedException ()
#1  0x023fba60 in threadPaused ()
#2  0x02412a50 in stg_returnToSched ()
#3  0x02412a50 in stg_returnToSched ()

The same is not happening on the 6.13 head branch. There stage2 works ok. In addition the 6.12.1 release works ok.

The rts/RaiseAsync.c file containing maybePerformBlockedException is currently identical between the stable and head branches.

Sadly, relinking stage2 with -debug does not shed any light on things. We get a segfault with a different backtrace

#0  0x02399580 in integer_cmm_int2Integerzh ()
#1  0x02397984 in sJ9_info ()
#2  0x02397984 in sJ9_info ()

Of course since this is a cmm function there is no symbolic debug info.

[simonmar]

I tried building the stable branch on sparky, and I get

"inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wcast-align -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Irts -optc-DCOMPILING_RTS -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-Ilibffi/build/include -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -optc-w   -H64m -O0 -fasm -Iincludes -Irts -DCOMPILING_RTS -package-name rts -static  -dcmm-lint  -Ilibffi/build/include     -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen          -optc-O2   -c rts/StgCRun.c -o rts/dist/build/StgCRun.o
/opt/gcc/bin/../../SUNW0scgfss/4.0.4/prod/bin/fbe: "/tmp/ghc18508_0/ghc18508_0.s", line 18: error: statement syntax
/opt/gcc/bin/../../SUNW0scgfss/4.0.4/prod/bin/fbe: "/tmp/ghc18508_0/ghc18508_0.s", line 32: error: statement syntax

the .s file in question is

        .section        ".text",#alloc,#execinstr,#progbits
        .file   "StgCRun.c"
        .hidden StgRun

        .section        ".text",#alloc,#execinstr,#progbits
        .align  4


        .global StgRun
StgRun: 
        sethi   %hi(0x2000),%g1
        xor     %g1,-96,%g1
        save    %sp,%g1,%sp
        jmpl    %i0,%o7
        nop
        sethi   %hi(0x1c00),%g1
        sethi   %hi(%l1),%i5
        xor     %g1,-1024,%g1
        add     %g1,%fp,%g1
        or      %g0,%g1,%o0

.L900000111:    
        .align  4

.L900000112:    
        .global StgReturn

.L900000113:    

.L900000114:    
        ld      [%i5+%lo(%l1)],%i0
        ret     ! Result =  %i0
        restore %g0,%g0,%g0
        .type   StgRun,2
        .size   StgRun,(.-StgRun)
        .ident  "cg: Sun Compiler Common 12 SunOS_sparc gccfss_lang 2007/07/11"
        .ident  "GCC: (GNU) 4.0.4 (gccfss)"
        .ident  "iropt: Sun Compiler Common 12 SunOS_sparc gccfss_lang 2007/07/11"

any ideas?

[simonmar]

After fixing my build, I'm not seeing this bug. Let's re-open the ticket if it comes back.

[maeder]

Sometimes I get "Bus Error" or "Segmentation Fault" as the last action of a ghc call (i.e. after deleting temp dirs), although everything was processed correctly.

These failures can also be seen in  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/ghc-6.12.3-tests.log.gz

-bash-3.00$ gcc -v
-bash-3.00$ uname -a
SunOS leo 5.10 Generic_142900-15 sun4u sparc SUNW,Sun-Fire-280R
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC)

[maeder]

I've made a new ticket #4475 since I do no longer see a relation to the original problem.