<div dir="ltr">I have a suspicion that the segmentation faults are related to fork errors, which appear in logs from time to time. After a few builds fork() errors become very frequent, and segfaults seem to occur more often. I just ran the build (validate.sh) in a loop, and after a while got a bunch of segfaults in Makefile rules as basic as rm invocations in the initial "make clean", e.g.:<div><br></div><div><div>"rm" -rf driver/split/dist</div><div>driver/split/<a href="http://ghc.mk:19">ghc.mk:19</a>: recipe for target 'clean_driver/split_dist' failed</div><div>make[1]: *** [clean_driver/split_dist] Segmentation fault</div><div>Makefile:94: recipe for target 'maintainer-clean' failed</div><div><br></div><div>Closing and reopening the msys2 console seems to help - for some time.</div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly <span dir="ltr"><<a href="mailto:mingw.android@gmail.com" target="_blank">mingw.android@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas<br>
<<a href="mailto:gintautas.miliauskas@gmail.com">gintautas.miliauskas@gmail.com</a>> wrote:<br>
> +ghc-devs<br>
><br>
> Hi Ray,<br>
><br>
> thanks for the feedback. ghc-stage1 is a native application, it is built<br>
> using a host ghc and a mingw gcc bundled with the ghc distribution (in order<br>
> to keep Windows builds more predictable). The thing is, the same builds<br>
> (using make) that were stable on cygwin seem to be crashing on msys2, even<br>
> though the (bundled) gcc used for the build is the same. It could be that<br>
> msys2 is triggering a bug in ghc somehow, but it could be something going on<br>
> in msys2 itself.<br>
><br>
> The tricky part is that the crashes are rare, one in thousands of ghc<br>
> invocations within a make build, and I'm having trouble pinning one down to<br>
> investigate. I'll try some basic tracing first, but ideas for something more<br>
> sophisticated would be very helpful.<br>
<br>
</span>Ah, ok. I skim read your initial email and applied totally incorrect<br>
weighting to the "not very hard to reproduce" bit, apologies!<br>
<br>
It *should* be possible to setup post-mortem debugging using either Qt<br>
Creator (Tools->Options->Debugger, tick "Use Qt Creator for<br>
post-mortem debugging") or Dr. Mingw<br>
(<a href="https://github.com/jrfonseca/drmingw" target="_blank">https://github.com/jrfonseca/drmingw</a>). I briefly tested both options:<br>
<br>
Qt Creator: It seems there's a bug in its handling of the<br>
-wincrashevent command line which I've just added a note about to the<br>
MINGW-packages todo list since I'd find this feature more than very<br>
useful:<br>
<a href="https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md" target="_blank">https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md</a><br>
<br>
Dr Mingw: Launching the crashing executable from Windows Explorer, it<br>
launches it and gives me useful information.<br>
<br>
Unfortunately, regardless of the debugger used, when invoking the<br>
crashing executable from the mintty commandline, something inhibits<br>
all post mortem debugging. I will ask the mingw-w64 guys if they know<br>
what this is. I guess intrusive dialogs would be annoying, but I'd<br>
like an env. var override for that I think.<br>
<br>
There is another possibility, and that's that bash is crashing, which<br>
is an MSYS2 program. We do have a way of hooking into post-mortem<br>
debugging there since Cygwin provided a way and we improved it. If you<br>
check your msys2_shell.bat you'll see:<br>
rem set MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|<process-id><br>
<br>
If you remove the rem and make sure the path is correct (it may have<br>
rotted some since I last used it) then hopefully you'll get something<br>
useful. To be really useful, you should rebuild two packages,<br>
MSYS2-packages/{msys2-runtime,bash}/PKGBUILD with<br>
options=('debug' '!strip')<br>
and then install them.<br>
<br>
Finally, can anyone else confirm the problem?<br>
<br>
There may be some edge cases when e.g. PATH is around 1024 characters,<br>
I've seen some hardcoded limits in the msys2-runtime (nee Cygwin)<br>
code base for things like that. I'd advise cutting your Windows PATH<br>
down to just the essentials.<br>
<br>
Cheers,<br>
<br>
Ray.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit<br>
> tricky (some Haskell tools need to be preinstalled). I'm not sure how useful<br>
> it would be since for Windows there is already a nicely packaged native<br>
> Haskell Platform installer.<br>
><br>
><br>
> On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly <<a href="mailto:mingw.android@gmail.com">mingw.android@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas<br>
>> <<a href="mailto:gintautas.miliauskas@gmail.com">gintautas.miliauskas@gmail.com</a>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > I have been working on building GHC, the Glasgow Haskell Compiler, on<br>
>> > Windows using msys2 [1]. We have been having some strange trouble with<br>
>> > ghc<br>
>> > segfaulting during the bootstrapping process (i.e., during make). The<br>
>> > crashes are not very hard to reproduce, but they are not predictable<br>
>> > either.<br>
>> > This is almost certainly a bug in ghc itself and not with msys2<br>
>> > (although<br>
>> > the crashes do not seem to occur in other environments), but I've been<br>
>> > having some trouble pinning it down.<br>
>> ><br>
>><br>
>> Hi Gintuatas,<br>
>><br>
>> Great. I spotted that MSYS2 was the recommended env. for GHC on<br>
>> Windows, hopefully it will remain so!<br>
>><br>
>> > What's a good way to debug such crashes? Is it possible to somehow stop<br>
>> > the<br>
>> > ghc process when it segfaults and attach gdb, or to dump core somehow<br>
>> > for<br>
>> > later inspection?<br>
>> ><br>
>> > [1] <a href="https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows</a><br>
>> ><br>
>> > Here's one example crash:<br>
>> ><br>
>> > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m<br>
>> > -O<br>
>> > -Werror -Wall -H64m -O0    -this-package-key ghc_4ugNArSu5ba0Z1uHXrbTlU<br>
>> > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm<br>
>> > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci<br>
>> > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main<br>
>> > -icompiler/nativeGen -icompiler/parser -icompiler/prelude<br>
>> > -icompiler/profiling -icompiler/rename -icompiler/simplCore<br>
>> > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn<br>
>> > -icompiler/stranal -icompiler/typecheck -icompiler/types<br>
>> > -icompiler/utils<br>
>> > -icompiler/vectorise -icompiler/stage2/build<br>
>> > -icompiler/stage2/build/autogen<br>
>> > -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/.<br>
>> > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build<br>
>> > -Icompiler/stage2   -optP-DGHCI -optP-include<br>
>> > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key<br>
>> > Win32_43THQMouBnk2wpnouztX1X -package-key array_GX4NwjS8xZkC2ZPtjgwhnz<br>
>> > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key<br>
>> > binpa_17GphrLqCXt1H1lm4Kse1p -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv<br>
>> > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key<br>
>> > direc_HU5aFxMIQNwGQFzisjuinu -package-key filep_34DFDFT9FVD9pRLLgh8IdQ<br>
>> > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key<br>
>> > hpc_1QTsfQSN40FHN9p3mydARY -package-key proce_7ZlAbRkwiRO8qgXx3NNP0G<br>
>> > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key<br>
>> > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key trans_5jw4w9yTgmZ89ByuixDAKP<br>
>> > -Wall<br>
>> > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010<br>
>> > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing<br>
>> > -O2<br>
>> > -fwarn-tabs -O -dcore-lint  -no-user-package-db -rtsopts      -odir<br>
>> > compiler/stage2/build -hidir compiler/stage2/build -stubdir<br>
>> > compiler/stage2/build   -c compiler/basicTypes/UniqSupply.lhs -o<br>
>> > compiler/stage2/build/UniqSupply.o<br>
>> ><br>
>> > compiler/<a href="http://ghc.mk:657" target="_blank">ghc.mk:657</a>: recipe for target<br>
>> > 'compiler/stage2/build/UniqSupply.o'<br>
>> > failed<br>
>> > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation fault<br>
>> ><br>
>><br>
>> Well, it's pretty much the same story as with Linux. Build the<br>
>> executable and as many libraries as you can with (something like)<br>
>> "-ggdb -O0" then use gdb command line or some IDE of choice.<br>
>> Personally I use Qt Creator (we have packages for this) as it can<br>
>> debug external programs and, even though I don't dislike command<br>
>> lines, I find debugging from them a bit too masochistic.<br>
>><br>
>> Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is<br>
>> it built with exactly?<br>
>><br>
>> What would be involved in creating a PKGBUILD for ghc? We'd love to<br>
>> have one, and it'd certainly make me a lot more inclined to dive in to<br>
>> see what's going on if one existed already.<br>
>><br>
>> Ray.<br>
>><br>
>> ><br>
>> > --<br>
>> > Gintautas Miliauskas<br>
>> ><br>
>> ><br>
>> > ------------------------------------------------------------------------------<br>
>> ><br>
>> > _______________________________________________<br>
>> > Msys2-users mailing list<br>
>> > <a href="mailto:Msys2-users@lists.sourceforge.net">Msys2-users@lists.sourceforge.net</a><br>
>> > <a href="https://lists.sourceforge.net/lists/listinfo/msys2-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/msys2-users</a><br>
>> ><br>
><br>
><br>
><br>
><br>
> --<br>
> Gintautas Miliauskas<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Gintautas Miliauskas</div>
</div>