[Msys2-users] Debugging undeterministic segfaults

[Gintautas Miliauskas]

>
>
> thanks for the feedback. ghc-stage1 is a native application, it is built
> using a host ghc and a mingw gcc bundled with the ghc distribution (in
> order to keep Windows builds more predictable). The thing is, the same
> builds (using make) that were stable on cygwin seem to be crashing on
> msys2, even though the (bundled) gcc used for the build is the same. It
> could be that msys2 is triggering a bug in ghc somehow, but it could be
> something going on in msys2 itself.
>

Interesting data point: in one of my experiments the following command
segfaulted:

"inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Werror
-optc-Wall -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-Wnested-externs -optc-Wredundant-decls -optc-Iincludes
-optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common
-optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer
-optc-fno-omit-frame-pointer -optc-g -optc-O0
-optc-DRtsWay=\"rts_thr_debug\" -static -optc-DTHREADED_RTS -optc-DDEBUG
 -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header
-Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint
 -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build
-Irts/dist/build/autogen           -O2 -O0    -c rts/sm/GCUtils.c -o
rts/dist/build/sm/GCUtils.thr_debug_o
[...]
rts/ghc.mk:236: recipe for target 'rts/dist/build/sm/GCUtils.thr_debug_o'
failed
make[1]: *** [rts/dist/build/sm/GCUtils.thr_debug_o] Segmentation fault
make[1]: *** Deleting file 'rts/dist/build/sm/GCUtils.thr_debug_o'

Note that while the command is invoking ghc, actually it is only building a
C file, so it's just forwarding on the work to gcc The issue is thus
unlikely to be somewhere deep in ghc, it's either on the surface or in
msys2. There could be a problem with our gcc build, but other compiler
versions crash too, so I don't think that's it.


-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/dc056827/attachment.html>