Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-03 Thread Gintautas Miliauskas 
+ghc-devs

Hi Ray,

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.

The tricky part is that the crashes are rare, one in thousands of ghc
invocations within a make build, and I'm having trouble pinning one down to
investigate. I'll try some basic tracing first, but ideas for something
more sophisticated would be very helpful.

A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit
tricky (some Haskell tools need to be preinstalled). I'm not sure how
useful it would be since for Windows there is already a nicely packaged
native Haskell Platform installer.


On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly 
wrote:

> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas
>  wrote:
> > Hello,
> >
> > I have been working on building GHC, the Glasgow Haskell Compiler, on
> > Windows using msys2 [1]. We have been having some strange trouble with
> ghc
> > segfaulting during the bootstrapping process (i.e., during make). The
> > crashes are not very hard to reproduce, but they are not predictable
> either.
> > This is almost certainly a bug in ghc itself and not with msys2 (although
> > the crashes do not seem to occur in other environments), but I've been
> > having some trouble pinning it down.
> >
>
> Hi Gintuatas,
>
> Great. I spotted that MSYS2 was the recommended env. for GHC on
> Windows, hopefully it will remain so!
>
> > What's a good way to debug such crashes? Is it possible to somehow stop
> the
> > ghc process when it segfaults and attach gdb, or to dump core somehow for
> > later inspection?
> >
> > [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
> >
> > Here's one example crash:
> >
> > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m
> -O
> > -Werror -Wall -H64m -O0-this-package-key ghc_4ugNArSu5ba0Z1uHXrbTlU
> > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm
> > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci
> > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main
> > -icompiler/nativeGen -icompiler/parser -icompiler/prelude
> > -icompiler/profiling -icompiler/rename -icompiler/simplCore
> > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn
> > -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils
> > -icompiler/vectorise -icompiler/stage2/build
> -icompiler/stage2/build/autogen
> > -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/.
> > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build
> > -Icompiler/stage2   -optP-DGHCI -optP-include
> > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key
> > Win32_43THQMouBnk2wpnouztX1X -package-key array_GX4NwjS8xZkC2ZPtjgwhnz
> > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key
> > binpa_17GphrLqCXt1H1lm4Kse1p -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv
> > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key
> > direc_HU5aFxMIQNwGQFzisjuinu -package-key filep_34DFDFT9FVD9pRLLgh8IdQ
> > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key
> > hpc_1QTsfQSN40FHN9p3mydARY -package-key proce_7ZlAbRkwiRO8qgXx3NNP0G
> > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key
> > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key trans_5jw4w9yTgmZ89ByuixDAKP
> -Wall
> > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010
> > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2
> > -fwarn-tabs -O -dcore-lint  -no-user-package-db -rtsopts  -odir
> > compiler/stage2/build -hidir compiler/stage2/build -stubdir
> > compiler/stage2/build   -c compiler/basicTypes/UniqSupply.lhs -o
> > compiler/stage2/build/UniqSupply.o
> >
> > compiler/ghc.mk:657: recipe for target
> 'compiler/stage2/build/UniqSupply.o'
> > failed
> > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation fault
> >
>
> Well, it's pretty much the same story as with Linux. Build the
> executable and as many libraries as you can with (something like)
> "-ggdb -O0" then use gdb command line or some IDE of choice.
> Personally I use Qt Creator (we have packages for this) as it can
> debug external programs and, even though I don't dislike command
> lines, I find debugging from them a bit too masochistic.
>
> Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is
> it built with exactly?
>
> What would be involved in creating a PKGBUILD for ghc? We'd love to
> have one, and it'd certainly make me a lot more inclined to dive in to
> see what's going on if one existed already.
>
> Ray.
>
> >
> > --
> > Gintautas Miliauskas
> >
> >
> ---

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-03 Thread David Macek 
On 4. 11. 2014 0:07, Gintautas Miliauskas wrote:
> A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit 
> tricky (some Haskell tools need to be preinstalled). I'm not sure how useful 
> it would be since for Windows there is already a nicely packaged native 
> Haskell Platform installer.

It definitely helps MSYS2 users by providing an easily installable ghc package. 
That in turn could help with setting up ghc development environment. Hopefully 
after Windows ghc migrates to gcc 4.8, ghc package will be able to use the 
MSYS2 packaged toolchain to reduce duplication.

I have this so far, but I give no guarantees: 
https://github.com/elieux/MINGW-packages/tree/ghc

To use:
- download ghc and put it in PATH
- optionally alter ghc/lib/settings to use MSYS2 toolchain instead of the 
bundled one (see below)
- use cabal-install PKGBUILD to build Cabal and put it in PATH
- use built Cabal to download and build Alex and Happy and put them in PATH (I 
think they're installed somewhere inside AppData by default)
- run ghc PKGBUILD

Related: https://www.haskell.org/pipermail/ghc-devs/2014-October/006759.html

My ghc/lib/settings (from version 7.6.3):

[("GCC extra via C opts", " -fwrapv"),
 ("C compiler command", "gcc.exe"),
 ("C compiler flags", " -fno-stack-protector  -Wl,--hash-size=31 
-Wl,--reduce-memory-overheads"),
 ("ar command", "ar.exe"),
 ("ar flags", "q"),
 ("ar supports at file", "YES"),
 ("touch command", "$topdir/touchy.exe"),
 ("dllwrap command", "dllwrap.exe"),
 ("windres command", "windres.exe"),
 ("perl command", "perl.exe"),
 ("target os", "OSMinGW32"),
 ("target arch", "ArchX86_64"),
 ("target word size", "8"),
 ("target has GNU nonexec stack", "False"),
 ("target has .ident directive", "True"),
 ("target has subsections via symbols", "False"),
 ("LLVM llc command", ""),
 ("LLVM opt command", "")
 ]

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-03 Thread Gintautas Miliauskas 
Nice!

This needs a host ghc (with alex and happy) preinstalled, correct?

On Tue, Nov 4, 2014 at 12:55 AM, David Macek 
wrote:

> On 4. 11. 2014 0:07, Gintautas Miliauskas wrote:
> > A PKGBUILD for ghc should be feasible, although the bootstrapping is a
> bit tricky (some Haskell tools need to be preinstalled). I'm not sure how
> useful it would be since for Windows there is already a nicely packaged
> native Haskell Platform installer.
>
> It definitely helps MSYS2 users by providing an easily installable ghc
> package. That in turn could help with setting up ghc development
> environment. Hopefully after Windows ghc migrates to gcc 4.8, ghc package
> will be able to use the MSYS2 packaged toolchain to reduce duplication.
>
> I have this so far, but I give no guarantees:
> https://github.com/elieux/MINGW-packages/tree/ghc
>
> To use:
> - download ghc and put it in PATH
> - optionally alter ghc/lib/settings to use MSYS2 toolchain instead of the
> bundled one (see below)
> - use cabal-install PKGBUILD to build Cabal and put it in PATH
> - use built Cabal to download and build Alex and Happy and put them in
> PATH (I think they're installed somewhere inside AppData by default)
> - run ghc PKGBUILD
>
> Related:
> https://www.haskell.org/pipermail/ghc-devs/2014-October/006759.html
>
> My ghc/lib/settings (from version 7.6.3):
>
> [("GCC extra via C opts", " -fwrapv"),
>  ("C compiler command", "gcc.exe"),
>  ("C compiler flags", " -fno-stack-protector  -Wl,--hash-size=31
> -Wl,--reduce-memory-overheads"),
>  ("ar command", "ar.exe"),
>  ("ar flags", "q"),
>  ("ar supports at file", "YES"),
>  ("touch command", "$topdir/touchy.exe"),
>  ("dllwrap command", "dllwrap.exe"),
>  ("windres command", "windres.exe"),
>  ("perl command", "perl.exe"),
>  ("target os", "OSMinGW32"),
>  ("target arch", "ArchX86_64"),
>  ("target word size", "8"),
>  ("target has GNU nonexec stack", "False"),
>  ("target has .ident directive", "True"),
>  ("target has subsections via symbols", "False"),
>  ("LLVM llc command", ""),
>  ("LLVM opt command", "")
>  ]
>
> --
> David Macek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-03 Thread David Macek 
On 4. 11. 2014 1:05, Gintautas Miliauskas wrote:
> Nice!
> 
> This needs a host ghc (with alex and happy) preinstalled, correct?

Maybe I misunderstood, but the answer should be clear from my message. Yes, the 
ghc PKGBUILD expects working ghc, alex and happy in PATH. ghc has to be 
downloaded (until an MSYS2 package becomes available), cabal can be built using 
cabal-install PKGBUILD and alex and happy can then be downloaded and built 
using cabal.

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-03 Thread 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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-03 Thread Gintautas Miliauskas 
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.:

"rm" -rf driver/split/dist
driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist' failed
make[1]: *** [clean_driver/split_dist] Segmentation fault
Makefile:94: recipe for target 'maintainer-clean' failed

Closing and reopening the msys2 console seems to help - for some time.




On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly 
wrote:

> On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas
>  wrote:
> > +ghc-devs
> >
> > Hi Ray,
> >
> > 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.
> >
> > The tricky part is that the crashes are rare, one in thousands of ghc
> > invocations within a make build, and I'm having trouble pinning one down
> to
> > investigate. I'll try some basic tracing first, but ideas for something
> more
> > sophisticated would be very helpful.
>
> Ah, ok. I skim read your initial email and applied totally incorrect
> weighting to the "not very hard to reproduce" bit, apologies!
>
> It *should* be possible to setup post-mortem debugging using either Qt
> Creator (Tools->Options->Debugger, tick "Use Qt Creator for
> post-mortem debugging") or Dr. Mingw
> (https://github.com/jrfonseca/drmingw). I briefly tested both options:
>
> Qt Creator: It seems there's a bug in its handling of the
> -wincrashevent command line which I've just added a note about to the
> MINGW-packages todo list since I'd find this feature more than very
> useful:
> https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md
>
> Dr Mingw: Launching the crashing executable from Windows Explorer, it
> launches it and gives me useful information.
>
> Unfortunately, regardless of the debugger used, when invoking the
> crashing executable from the mintty commandline, something inhibits
> all post mortem debugging. I will ask the mingw-w64 guys if they know
> what this is. I guess intrusive dialogs would be annoying, but I'd
> like an env. var override for that I think.
>
> There is another possibility, and that's that bash is crashing, which
> is an MSYS2 program. We do have a way of hooking into post-mortem
> debugging there since Cygwin provided a way and we improved it. If you
> check your msys2_shell.bat you'll see:
> rem set
> MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|
>
> If you remove the rem and make sure the path is correct (it may have
> rotted some since I last used it) then hopefully you'll get something
> useful. To be really useful, you should rebuild two packages,
> MSYS2-packages/{msys2-runtime,bash}/PKGBUILD with
> options=('debug' '!strip')
> and then install them.
>
> Finally, can anyone else confirm the problem?
>
> There may be some edge cases when e.g. PATH is around 1024 characters,
> I've seen some hardcoded limits in the msys2-runtime (nee Cygwin)
> code base for things like that. I'd advise cutting your Windows PATH
> down to just the essentials.
>
> Cheers,
>
> Ray.
>
> >
> > A PKGBUILD for ghc should be feasible, although the bootstrapping is a
> bit
> > tricky (some Haskell tools need to be preinstalled). I'm not sure how
> useful
> > it would be since for Windows there is already a nicely packaged native
> > Haskell Platform installer.
> >
> >
> > On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly 
> > wrote:
> >>
> >> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas
> >>  wrote:
> >> > Hello,
> >> >
> >> > I have been working on building GHC, the Glasgow Haskell Compiler, on
> >> > Windows using msys2 [1]. We have been having some strange trouble with
> >> > ghc
> >> > segfaulting during the bootstrapping process (i.e., during make). The
> >> > crashes are not very hard to reproduce, but they are not predictable
> >> > either.
> >> > This is almost certainly a bug in ghc itself and not with msys2
> >> > (although
> >> > the crashes do not seem to occur in other environments), but I've been
> >> > having some trouble pinning it down.
> >> >
> >>
> >> Hi Gintuatas,
> >>
> >> Great. I spotted that MSYS2 was the recommended env. for GHC on
> >> Windows, hopefully it will remain so!
> >>
> >> > What's a good way to debug such crashes? Is it possible to somehow
> stop
> >> > the
> >> > ghc process when it segfaults and attach gdb, or to dump core somehow
> >>

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread Gintautas Miliauskas 
I had a problem  with
building msys2-runtime, but debug bash installed successfully.
I uncommented the hook to invoke qtcreator.exe on crashing (your .bat file
needs escaping, puill request pending...), but I'm not quite sure how to
check that it works. I tried building this crasher program with
/usr/bin/gcc:

#include 
int main() {
  char *s = 0;
  printf("hi\n");
  printf("%s\n", s);
  printf("bye\n");
  return 0;
}

But running it just prints "hi", no indications of a crash or anything,
regardless of the value of the MSYS variable:

$ /usr/bin/gcc -o crash crash.c
$ ./crash.exe
hi
$ echo $?
0



On Tue, Nov 4, 2014 at 1:56 AM, Ray Donnelly 
wrote:

> On Tue, Nov 4, 2014 at 12:45 AM, Gintautas Miliauskas
>  wrote:
> > 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.:
> >
> > "rm" -rf driver/split/dist
> > driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist'
> failed
> > make[1]: *** [clean_driver/split_dist] Segmentation fault
> > Makefile:94: recipe for target 'maintainer-clean' failed
> >
> > Closing and reopening the msys2 console seems to help - for some time.
>
> Interesting .. how much process spawning do you think happens? On
> MSYS2 we run massive builds (bootstrapping builds of GCC for 2 arches
> for example), but MSYS2 shares a memory map, so heap corruption could
> happen and cause later problems. My recommendation about building
> debug bash and msys2-runtime and set
> MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|
> stands all the more then. You may need to setup path mappings in Qt C
> to map from MSYS2 paths to Windows paths. You need to do this as QtC
> needs to use the native GDB instead of the MSYS2 one so that QtC and
> GDB are in the same pathing namespace.
>
> There may be a way of building msys2-runtime to check for memory
> overruns too, perhaps just building it with the 'debug' option will
> enable that, I'm not sure ..
>
> >
> >
> >
> >
> > On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly 
> > wrote:
> >>
> >> On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas
> >>  wrote:
> >> > +ghc-devs
> >> >
> >> > Hi Ray,
> >> >
> >> > 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.
> >> >
> >> > The tricky part is that the crashes are rare, one in thousands of ghc
> >> > invocations within a make build, and I'm having trouble pinning one
> down
> >> > to
> >> > investigate. I'll try some basic tracing first, but ideas for
> something
> >> > more
> >> > sophisticated would be very helpful.
> >>
> >> Ah, ok. I skim read your initial email and applied totally incorrect
> >> weighting to the "not very hard to reproduce" bit, apologies!
> >>
> >> It *should* be possible to setup post-mortem debugging using either Qt
> >> Creator (Tools->Options->Debugger, tick "Use Qt Creator for
> >> post-mortem debugging") or Dr. Mingw
> >> (https://github.com/jrfonseca/drmingw). I briefly tested both options:
> >>
> >> Qt Creator: It seems there's a bug in its handling of the
> >> -wincrashevent command line which I've just added a note about to the
> >> MINGW-packages todo list since I'd find this feature more than very
> >> useful:
> >> https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md
> >>
> >> Dr Mingw: Launching the crashing executable from Windows Explorer, it
> >> launches it and gives me useful information.
> >>
> >> Unfortunately, regardless of the debugger used, when invoking the
> >> crashing executable from the mintty commandline, something inhibits
> >> all post mortem debugging. I will ask the mingw-w64 guys if they know
> >> what this is. I guess intrusive dialogs would be annoying, but I'd
> >> like an env. var override for that I think.
> >>
> >> There is another possibility, and that's that bash is crashing, which
> >> is an MSYS2 program. We do have a way of hooking into post-mortem
> >> debugging there since Cygwin provided a way and we improved it. If you
> >> check your msys2_shell.bat you'll see:
> >> rem set
> >> MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|
> >>
> >> If you remove the rem and make sure the path is correct (it may have
> >> rotted s

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread David Macek 
On 4. 11. 2014 13:07, Gintautas Miliauskas wrote:
> But running it just prints "hi", no indications of a crash or anything, 
> regardless of the value of the MSYS variable:

Either the compiler, or C library is too smart for this. I'd guess your 
compiler is working with undefined behavior optimizations, because with my 
compiler, I get both "hi" and "bye" (or not, when I pass -Og). Try this code:

#include 
int main() {
  printf("hi\n");
  ((void(*)())(0))();
  printf("bye\n");
  return 0;
}


-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread David Macek 
On 4. 11. 2014 1:30, Ray Donnelly wrote:
> Finally, can anyone else confirm the problem?

I'm sorry if I missed it, but I can't find what source version you're using, 
Gintautas. Release/trunk?

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread Gintautas Miliauskas 
I'm working on ghc trunk.

You were indeed right, the compiler was probably optimizing out my code.
The suggested crasher code works, and qtcreator gets invoked, although I
did not manage to set up gdb yet.

I think I have an idea of what's going wrong here. hvr@ was right in
pointing out that we need to be careful with the PATH. It seems that the
bundled gcc is picking up the system-wide DLLs, and bad things happen
because of version incompatibilities. That does not explain why "rm" is
crashing, but maybe that's fallout from cross-process damage. I will do
some more testing. If this is indeed the cause, then hopefully debugging
will not be needed anyway.

On Tue, Nov 4, 2014 at 1:57 PM, David Macek  wrote:

> On 4. 11. 2014 1:30, Ray Donnelly wrote:
> > Finally, can anyone else confirm the problem?
>
> I'm sorry if I missed it, but I can't find what source version you're
> using, Gintautas. Release/trunk?
>
> --
> David Macek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread David Macek 
On 4. 11. 2014 14:14, Gintautas Miliauskas wrote:
> I'm working on ghc trunk.

I'm trying to reproduce your errors, but I failed at ./boot with:

Booting .
'autoreconf' is not recognized as an internal or external command,
operable program or batch file.
Running autoreconf failed with exitcode 256 at ./boot line 163,  line 12.

It seems that /mingw64/bin/perl's system("autoreconf") fails to execute because 
it's passing the command line to cmd, not bash (/usr/bin/autoreconf is a 
script).

Gintautas, do you have mingw-w64-x86_64-perl installed?

Can we do something about this, or is boot going to work only in pure msys2 
shell?

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread Gintautas Miliauskas 
>
>
> I think I have an idea of what's going wrong here. hvr@ was right in
> pointing out that we need to be careful with the PATH. It seems that the
> bundled gcc is picking up the system-wide DLLs, and bad things happen
> because of version incompatibilities. That does not explain why "rm" is
> crashing, but maybe that's fallout from cross-process damage. I will do
> some more testing. If this is indeed the cause, then hopefully debugging
> will not be needed anyway.
>

Update: even after setting PATH to have the embedded gcc path in the first
position to make sure that the right DLLs are, I still got a few segfaults,
so this is probably not it.

-- 
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread Gintautas Miliauskas 
I'm using /usr/bin/perl, and don't have the mingw perl installed.

On Tue, Nov 4, 2014 at 4:10 PM, David Macek  wrote:

> On 4. 11. 2014 14:14, Gintautas Miliauskas wrote:
> > I'm working on ghc trunk.
>
> I'm trying to reproduce your errors, but I failed at ./boot with:
>
> Booting .
> 'autoreconf' is not recognized as an internal or external command,
> operable program or batch file.
> Running autoreconf failed with exitcode 256 at ./boot line 163, 
> line 12.
>
> It seems that /mingw64/bin/perl's system("autoreconf") fails to execute
> because it's passing the command line to cmd, not bash (/usr/bin/autoreconf
> is a script).
>
> Gintautas, do you have mingw-w64-x86_64-perl installed?
>
> Can we do something about this, or is boot going to work only in pure
> msys2 shell?
>
> --
> David Macek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread David Macek 
Hi. I just built GHC from master (1c35f9f1cb7a293da85d649904ce731a65824cfe) in 
my somewhat outdated MSYS2. I followed the wiki page with a few exceptions.

- I cleared my PATH before running the shell (I left only Windows and System32)
- my installation is not up-to-date
- I do not have msys2 libtool, automake nor binutils; if the build used any of 
those, they came from mingw64 or from the host ghc
- I had to run boot in pure msys2 shell, because mingw64 perl caused it to fail

I saw no segfaults, but I may have missed them. I did not get a ghc.exe, but 
that may be correct behavior for all I know. My simple test program compiled 
and ran fine. I saw a lot of warnings during ghc's build though:

- checking for DocBook DTD... I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
- something with not finding any implementation of a module out of [ xxx.dylib, 
xxx, ... ], I think it was in cabal builds
- "could not find link destionations for: xxx"

I hope it helps somehow. Maybe your issues come from mixing msys2 and mingw 
toolchain after all.



-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread Gintautas Miliauskas 
Hi David,

ghc should appear as inplace/bin/ghc-stage2.exe after a successful build.

The warnings are expected.

Did you run make with parallelism? I don't have a smoking gun, but the
build seems to be somewhat stable with -j1, while it crashes a lot of the
time with -j5 (I have a 4-core CPU). I have only tried a couple of runs
with -j1 (takes a while...), so I can't say for sure that non-parallel
builds are stable, but 2/2 runs succeeded.

Another data point: I ran the validate script in a loop and stored the
logs, and most crashes seem to be in rts/, but not all of them. Not sure
why.

$ grep Segmentation *.log
1.log:make[1]: ***
[libraries/base/dist-install/build/Text/Show/Functions.o] Segmentation fault
10.log:make[1]: *** [rts/dist/build/Hpc.o] Segmentation fault
11.log:make[1]: *** [rts/dist/build/RtsFlags.thr_l_o] Segmentation fault
12.log:make[1]: *** [rts/dist/build/sm/GCAux.o] Segmentation fault
13.log:make[1]: *** [rts/dist/build/win32/GetEnv.thr_l_o] Segmentation fault
14.log:make[1]: *** [rts/dist/build/sm/Scav.l_o] Segmentation fault
15.log:make[1]: *** [compiler/stage1/build/RegAlloc/Linear/State.o]
Segmentation fault
18.log:make[1]: ***
[libraries/filepath/dist-install/build/.depend-v.haskell] Segmentation fault
19.log:make[1]: *** [libraries/base/dist-install/build/.depend-v.haskell]
Segmentation fault
4.log:make[1]: *** [rts/dist/build/RtsDllMain.o] Segmentation fault
5.log:make[1]: *** [rts/dist/build/sm/Evac_thr.thr_o] Segmentation fault
6.log:make[1]: *** [rts/dist/build/sm/Scav_thr.thr_l_o] Segmentation fault
7.log:make[1]: *** [rts/dist/build/Linker.thr_debug_o] Segmentation fault
8.log:make[1]: *** [rts/dist/build/sm/Storage.debug_o] Segmentation fault
9.log:make[1]: *** [rts/dist/build/hooks/OutOfHeap.thr_debug_o]
Segmentation fault


On Tue, Nov 4, 2014 at 7:43 PM, David Macek  wrote:

> Hi. I just built GHC from master
> (1c35f9f1cb7a293da85d649904ce731a65824cfe) in my somewhat outdated MSYS2. I
> followed the wiki page with a few exceptions.
>
> - I cleared my PATH before running the shell (I left only Windows and
> System32)
> - my installation is not up-to-date
> - I do not have msys2 libtool, automake nor binutils; if the build used
> any of those, they came from mingw64 or from the host ghc
> - I had to run boot in pure msys2 shell, because mingw64 perl caused it to
> fail
>
> I saw no segfaults, but I may have missed them. I did not get a ghc.exe,
> but that may be correct behavior for all I know. My simple test program
> compiled and ran fine. I saw a lot of warnings during ghc's build though:
>
> - checking for DocBook DTD... I/O error : Attempt to load network entity
> http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
> - something with not finding any implementation of a module out of [
> xxx.dylib, xxx, ... ], I think it was in cabal builds
> - "could not find link destionations for: xxx"
>
> I hope it helps somehow. Maybe your issues come from mixing msys2 and
> mingw toolchain after all.
>
>
>
> --
> David Macek
>
>
> --
> ___
> Msys2-users mailing list
> msys2-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>



-- 
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread David Macek 
On 4. 11. 2014 23:20, Gintautas Miliauskas wrote:
> ghc should appear as inplace/bin/ghc-stage2.exe after a successful build.

It's there.

> Did you run make with parallelism? I don't have a smoking gun, but the build 
> seems to be somewhat stable with -j1, while it crashes a lot of the time with 
> -j5 (I have a 4-core CPU). I have only tried a couple of runs with -j1 (takes 
> a while...), so I can't say for sure that non-parallel builds are stable, but 
> 2/2 runs succeeded.

Nope. I'll try with -j5.

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread Gintautas Miliauskas 
Oh, and David, thanks for your help. It's really appreciated. This issue
has been driving me nuts recently, and I don't have a good strategy to root
it out...

On Tue, Nov 4, 2014 at 11:23 PM, David Macek 
wrote:

> On 4. 11. 2014 23:20, Gintautas Miliauskas wrote:
> > ghc should appear as inplace/bin/ghc-stage2.exe after a successful build.
>
> It's there.
>
> > Did you run make with parallelism? I don't have a smoking gun, but the
> build seems to be somewhat stable with -j1, while it crashes a lot of the
> time with -j5 (I have a 4-core CPU). I have only tried a couple of runs
> with -j1 (takes a while...), so I can't say for sure that non-parallel
> builds are stable, but 2/2 runs succeeded.
>
> Nope. I'll try with -j5.
>
> --
> David Macek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-04 Thread David Macek 
On 4. 11. 2014 23:23, David Macek wrote:
> Nope. I'll try with -j5.

So that looks like another successful build. Unless "make" can ignore the -j 
argument, I'd say the issue is caused or activated by your configuration.

I'm running validate to double check (detected 4 CPUs). Maybe we should work 
out a precise, minimalistic recipe to replicate the issue (I haven't tried 
installing clean MSYS2 yet).

By the way, have you ruled out anti-virus software (and other BLODApps) as a 
possible cause?

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-05 Thread David Macek 
Sorry for the large amount of messages.

On 5. 11. 2014 8:01, David Macek wrote:
> I'm running validate to double check (detected 4 CPUs).

I got the validate results:

> Unexpected results from:
> TEST="linker_unload listCommand002 T5681 T5486 T7571 ghcpkg05 T3924 T7702 
> plugins01 T6106 ghci038 T8172 ghci032 T5975a T5975b ghci058 T3064 T3307 
> environment001 T876 T3738 T4830 T5205 T7436 lazy-bs-alloc T1407 rdynamic 
> T7037 T5423 T8124 T5435_dyn_asm prog012 prog013 prog001 prog002 prog003 T4006"
> 
> OVERALL SUMMARY for test run started at 11/05/14 09:04:01 Central Europe 
> Standard Time
>  1:01:50 spent to go through
> 4095 total tests, which gave rise to
>14911 test cases, of which
>11167 were skipped
> 
>   58 had missing libraries
> 3578 expected passes
>   71 expected failures
> 
>1 caused framework failures
>1 unexpected passes
>   36 unexpected failures
> 
> Unexpected passes:
>rts  linker_unload (normal)
> 
> Unexpected failures:
>../../libraries/base/tests T4006 [bad stdout] (normal)
>../../libraries/base/tests/IO  T3307 [bad exit code] (normal)
>../../libraries/base/tests/IO  environment001 [bad stdout] (normal)
>cabal  ghcpkg05 [bad stderr] (normal)
>callarity/perf T3924 [stat too good] (normal)
>ghci.debugger/scripts  listCommand002 [bad stderr] (ghci)
>ghci/linking   T1407 [bad stderr] (ghci)
>ghci/prog001   prog001 [bad stderr] (ghci)
>ghci/prog002   prog002 [bad stderr] (ghci)
>ghci/prog003   prog003 [bad exit code] (ghci)
>ghci/prog012   prog012 [bad stderr] (ghci)
>ghci/prog013   prog013 [bad stderr] (ghci)
>ghci/scripts   T5975a [bad stderr] (ghci)
>ghci/scripts   T5975b [bad stderr] (ghci)
>ghci/scripts   T6106 [bad stderr] (ghci)
>ghci/scripts   T8172 [bad stdout] (ghci)
>ghci/scripts   ghci032 [bad stderr] (ghci)
>ghci/scripts   ghci038 [bad stderr] (ghci)
>ghci/scripts   ghci058 [bad stderr] (ghci)
>llvm/should_compileT5486 [stderr mismatch] (optllvm)
>llvm/should_compileT5681 [stderr mismatch] (optllvm)
>llvm/should_compileT7571 [stderr mismatch] (optllvm)
>perf/compiler  T3064 [stat not good enough] (normal)
>perf/should_runT3738 [stat too good] (normal)
>perf/should_runT4830 [stat too good] (normal)
>perf/should_runT5205 [stat too good] (normal)
>perf/should_runT7436 [stat too good] (normal)
>perf/should_runT876 [stat not good enough] (normal)
>perf/should_runlazy-bs-alloc [stat not good enough] 
> (normal)
>pluginsplugins01 [bad stderr] (normal)
>rtsT5423 [bad stdout] (normal)
>rtsT5435_dyn_asm [bad stdout] (normal)
>rtsT7037 [bad stdout] (normal)
>rtsT8124 [exit code non-0] (threaded1)
>rtsrdynamic [bad exit code] (normal)
>simplCore/should_compile   T7702 [stderr mismatch] (normal)

I assume that means the build itself had no errors.

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-05 Thread Gintautas Miliauskas 
Hi David,

more messages means more progress on this issue, so fire away.

Your validate output looks reasonable, some tests are known to fail on
Windows.

I just verified that at least here the build seems to be stable with -j1:
40/40 builds were successful. Great! Now we know that something is up with
multithreaded make.

Thanks for pointing out that virus scanners could be an issue. I found that
Microsoft Security Essentials realtime scanning was on. I'll try disabling
it and see if that helps with the -j5 case.

> So that looks like another successful build. Unless "make" can ignore the
-j argument, I'd say the issue is caused or activated by your configuration.

I would be very happy if that were the case, but there were reports about
instabilities on msys2 from others too. Herbert wrote:

> PS: Fwiw, It seems to me the Cygwin environment seems more reliable
compared to the
>   Msys2 environment. On Cygwin I never had any aborted GHC builds,
>   while on Msys2 it seems to happen from time to time (but
 >  non-deterministic, and rather seldom)

Herbert, were you running make with -jN, N >1?


On Wed, Nov 5, 2014 at 11:36 AM, David Macek 
wrote:

> Sorry for the large amount of messages.
>
> On 5. 11. 2014 8:01, David Macek wrote:
> > I'm running validate to double check (detected 4 CPUs).
>
> I got the validate results:
>
> > Unexpected results from:
> > TEST="linker_unload listCommand002 T5681 T5486 T7571 ghcpkg05 T3924
> T7702 plugins01 T6106 ghci038 T8172 ghci032 T5975a T5975b ghci058 T3064
> T3307 environment001 T876 T3738 T4830 T5205 T7436 lazy-bs-alloc T1407
> rdynamic T7037 T5423 T8124 T5435_dyn_asm prog012 prog013 prog001 prog002
> prog003 T4006"
> >
> > OVERALL SUMMARY for test run started at 11/05/14 09:04:01 Central Europe
> Standard Time
> >  1:01:50 spent to go through
> > 4095 total tests, which gave rise to
> >14911 test cases, of which
> >11167 were skipped
> >
> >   58 had missing libraries
> > 3578 expected passes
> >   71 expected failures
> >
> >1 caused framework failures
> >1 unexpected passes
> >   36 unexpected failures
> >
> > Unexpected passes:
> >rts  linker_unload (normal)
> >
> > Unexpected failures:
> >../../libraries/base/tests T4006 [bad stdout] (normal)
> >../../libraries/base/tests/IO  T3307 [bad exit code] (normal)
> >../../libraries/base/tests/IO  environment001 [bad stdout] (normal)
> >cabal  ghcpkg05 [bad stderr] (normal)
> >callarity/perf T3924 [stat too good] (normal)
> >ghci.debugger/scripts  listCommand002 [bad stderr] (ghci)
> >ghci/linking   T1407 [bad stderr] (ghci)
> >ghci/prog001   prog001 [bad stderr] (ghci)
> >ghci/prog002   prog002 [bad stderr] (ghci)
> >ghci/prog003   prog003 [bad exit code] (ghci)
> >ghci/prog012   prog012 [bad stderr] (ghci)
> >ghci/prog013   prog013 [bad stderr] (ghci)
> >ghci/scripts   T5975a [bad stderr] (ghci)
> >ghci/scripts   T5975b [bad stderr] (ghci)
> >ghci/scripts   T6106 [bad stderr] (ghci)
> >ghci/scripts   T8172 [bad stdout] (ghci)
> >ghci/scripts   ghci032 [bad stderr] (ghci)
> >ghci/scripts   ghci038 [bad stderr] (ghci)
> >ghci/scripts   ghci058 [bad stderr] (ghci)
> >llvm/should_compileT5486 [stderr mismatch] (optllvm)
> >llvm/should_compileT5681 [stderr mismatch] (optllvm)
> >llvm/should_compileT7571 [stderr mismatch] (optllvm)
> >perf/compiler  T3064 [stat not good enough] (normal)
> >perf/should_runT3738 [stat too good] (normal)
> >perf/should_runT4830 [stat too good] (normal)
> >perf/should_runT5205 [stat too good] (normal)
> >perf/should_runT7436 [stat too good] (normal)
> >perf/should_runT876 [stat not good enough] (normal)
> >perf/should_runlazy-bs-alloc [stat not good enough]
> (normal)
> >pluginsplugins01 [bad stderr] (normal)
> >rtsT5423 [bad stdout] (normal)
> >rtsT5435_dyn_asm [bad stdout] (normal)
> >rtsT7037 [bad stdout] (normal)
> >rtsT8124 [exit code non-0] (threaded1)
> >rtsrdynamic [bad exit code] (normal)
> >simplCore/should_compile   T7702 [stderr mismatch] (normal)
>
> I assume that means the build itself had no errors.
>
> --
> David Macek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
_

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-05 Thread Gintautas Miliauskas 
>
> Thanks for pointing out that virus scanners could be an issue. I found
> that Microsoft Security Essentials realtime scanning was on. I'll try
> disabling it and see if that helps with the -j5 case.
>

For what it's worth, I tried disabling the virus scanner, but it did not
help, 4/8 validation runs segfaulted (-j5).


-- 
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-10 Thread David Macek 
On 5. 11. 2014 18:13, Gintautas Miliauskas wrote:
> 
> 
> Thanks for pointing out that virus scanners could be an issue. I found 
> that Microsoft Security Essentials realtime scanning was on. I'll try 
> disabling it and see if that helps with the -j5 case.
> 
> 
> For what it's worth, I tried disabling the virus scanner, but it did not 
> help, 4/8 validation runs segfaulted (-j5).

Can you dump your package versions here? Use pacman -Qe. I want to try the 
build with a replica of your environment.

Also, does 4/8 mean that some builds were without errors? Maybe I haven't done 
enough runs. Could you attach the script you use for running validate in a 
loop? (I'm sure it's simple enough for me to write it, but if I can avoid it...)

-- 
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-10 Thread Simon Marlow 

On 04/11/2014 15:44, Gintautas Miliauskas wrote:


I think I have an idea of what's going wrong here. hvr@ was right in
pointing out that we need to be careful with the PATH. It seems that
the bundled gcc is picking up the system-wide DLLs, and bad things
happen because of version incompatibilities. That does not explain
why "rm" is crashing, but maybe that's fallout from cross-process
damage. I will do some more testing. If this is indeed the cause,
then hopefully debugging will not be needed anyway.


Update: even after setting PATH to have the embedded gcc path in the
first position to make sure that the right DLLs are, I still got a few
segfaults, so this is probably not it.


Is it always GHC that segfaults, or one of the other programs it 
invokes, like gcc?


Have you tried to reproduce this on another machine, to rule out 
hardware problems?


Cheers,
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Msys2-users] Debugging undeterministic segfaults

2014-11-10 Thread Gintautas Miliauskas 
Hey,

I'm on vacation right now without access to my workstation, I will be back
in a couple weeks.

I believe hvr@ was having some stability issues too, maybe he can help
reproduce the problem?

Thanks for looking into this.

-- 
Gintautas Miliauskas
On Nov 10, 2014 6:24 PM, "David Macek"  wrote:

> On 5. 11. 2014 18:13, Gintautas Miliauskas wrote:
> >
> >
> > Thanks for pointing out that virus scanners could be an issue. I
> found that Microsoft Security Essentials realtime scanning was on. I'll try
> disabling it and see if that helps with the -j5 case.
> >
> >
> > For what it's worth, I tried disabling the virus scanner, but it did not
> help, 4/8 validation runs segfaulted (-j5).
>
> Can you dump your package versions here? Use pacman -Qe. I want to try the
> build with a replica of your environment.
>
> Also, does 4/8 mean that some builds were without errors? Maybe I haven't
> done enough runs. Could you attach the script you use for running validate
> in a loop? (I'm sure it's simple enough for me to write it, but if I can
> avoid it...)
>
> --
> David Macek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs