ghci and other test failures on Windows.
Simon Marlow
simonmar at microsoft.com
Tue Sep 7 06:33:42 EDT 2004
On 07 September 2004 04:43, Mike Thomas wrote:
> Thanks for your assistance.
>
> All the work listed below is done in a completed stable branch nightly
> build directory, using the hClose001 example.
>
> First, I noticed that just changing to a testsuite subdirectory and
> running make (which uses the stage 1 compiler by default) gives no
> crash as it does not proceed beyond the object module loading stage:
>
> $
> '/cygdrive/c/cvs/stable/i386-unknown-mingw32/ghc/compiler/ghc-inplace'
> -no-recomp -dcore-lint -Di386_unknown_mingw32 hClose001.hs
> --interactive
> -v0 <hClose001.script
>
>
c://cvs//stable//i386-unknown-mingw32/libraries/base/cbits/HSbase_cbits.
o:
> unknown symbol `_barf'
> ghc.exe: unable to load package `base'
I'm betting this is because you're running the stage1 compiler instead
of stage2. In a STABLE tree, the stage1 compiler gets built with GHCi
support because the build system thinks you're building with the same
version. When we bump the version to 6.2.2 this problem will go away.
> $ cat
> /cygdrive/c/cvs/stable/i386-unknown-mingw32/ghc/compiler/ghc-inplace
> #!/bin/sh
> exec c:/cvs/stable/i386-unknown-mingw32/ghc/compiler/stage1/ghc
> -Bc:\\\\cvs\\\\stable\\\\i386-unknown-mingw32 "$@"
>
> As the Makefile redirects the output to files it would be easy to
> assume that you were not getting the crash I am describing because
> that output is hidden from the build log.
If any errors occur, the test would fail and the testsuite driver would
show the actual output as diffs from the expected output (including
stderr). So it's unlikely that anything would get missed.
> Explicitly using a stage 2 or 3 compiler gives the crash however:
> $ c:/cvs/stable/i386-unknown-mingw32/ghc/compiler/stage2/ghc
> -Bc:\\\\cvs\\\\sta
> ble\\\\i386-unknown-mingw32 -no-recomp -dcore-lint
> -Di386_unknown_mingw32 hClo
> se001.hs --interactive -v0 <hClose001.script
> ===== program output begins here
> ===== program output begins here
Ok, I still don't get the crash.
> Second, the debugging output below is a bit iffy unless you happen to
> eat hexadecimal for breakfast, as the C files are missing. Worse than
> that, I suspect the C stack has been corrupted.
If the crash happens in Haskell rather than C code, then you won't get
any info from the C stack (the Haskell stack is separate). The output
from 'where' isn't much use. However, gdb should tell you the symbol of
the code fragment that the crash happened in, and you should be able to
get a disassembly (this is occasionally helpful).
Looking at your output, it appears that the crash did indeed happen in
Haskell code, so we're out of luck.
The best way to proceed would be to find the smallest program that
crashes - preferably just an ordinary compiled program rather than GHCi.
I wonder what's different about your setup compared to mine. Are you
running the latest mingw?
Cheers,
Simon
> Your advice on how to proceed with a debug build preserving necessary
> files would be greatly appreciated. If you get this email in time I
> may be able to set such a build up this evening.
>
> Cheers
>
> Mike Thomas.
>
>
> Simon Marlow wrote:
>> On 06 September 2004 11:14, Mike Thomas wrote:
>>
>>
>>> Thanks Simon.
>>>
>>>
>>>> I just ran the testsuite in lib/IO with an up to date STABLE build
>>>> on Windows, and I don't see the crashes you reported.
>>>
>>> Certainly one to ponder on for the future - I get a Windows
>>> exception dialog on all of those cases under both XP and NT 2000
>>> Pro.
>>
>>
>> Any chance you could investigate this further? I would try this:
>>
>> - re-link stage2 using EXTRA_HC_OPTS=-debug
>> - run one of the offending test cases under gdb
>>
>> Running the compiler under gdb is a bit fiddly: you need to gdb the
>> binary directly (not the ghc-inplace script), and pass the
>> appropriate -B option, which you can get from ghc-inplace. I
>> usually create a little .gdbinit file with a 'set args -B...'
>> command to set up the arguments.
>
> Did this for hClose001 both with and without +RTS -Ds -RTS:
>
> =========================================================
> $ cat .gdbinit
> set args -Bc:/cvs/stable/i386-unknown-mingw32 -no-recomp -dcore-lint
> -Di386_unknown_mingw32 hClose001.hs --interactive -v0
>
> $ cat hClose001.script
>> set prog hClose001
>> set args
> :! echo ===== program output begins here
> :! echo 1>&2 ===== program output begins here
> System.IO.hSetBuffering System.IO.stdout System.IO.LineBuffering
> GHC.TopHandler.runIO Main.main
>
> $ gdb
>
/cygdrive/c/cvs/stable/i386-unknown-mingw32/ghc/compiler/stage2/ghc.exe
> GNU gdb 2003-09-20-cvs (cygwin-special)
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details. This GDB was configured as "i686-pc-cygwin"...
> (gdb) r
> Starting program:
> /c/cvs/stable/i386-unknown-mingw32/ghc/compiler/stage2/ghc.exe
> -Bc:/cvs/stable/i386-unknown-mingw32 -no-recomp -dcore-lint
> -Di386_unknown_min
> gw32 hClose001.hs --interactive -v0
> *Main> :set prog hClose001
> *Main> :set args
> *Main> System.IO.hSetBuffering System.IO.stdout
> System.IO.LineBuffering
> *Main> GHC.TopHandler.runIO Main.main
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x119a2170 in ?? ()
> (gdb) bt
> #0 0x119a2170 in ?? ()
> #1 0x00000003 in ?? ()
> #2 0x0022de70 in ?? ()
> #3 0x1095a870 in ?? ()
> #4 0x01c49468 in ?? ()
> (gdb) info frame
> Stack level 0, frame at 0x22de64:
> eip = 0x119a2170; saved eip 0x3
> called by frame at 0x22de68
> Arglist at 0x22de5c, args:
> Locals at 0x22de5c, Previous frame's sp is 0x22de64
> Saved registers:
> eip at 0x22de60
> (gdb) up
> #1 0x00000003 in ?? ()
> (gdb) info frame
> Stack level 1, frame at 0x22de68:
> eip = 0x3; saved eip 0x22de70
> called by frame at 0x22de6c, caller of frame at 0x22de64
> Arglist at 0x22de60, args:
> Locals at 0x22de60, Previous frame's sp is 0x22de68
> Saved registers:
> eip at 0x22de64
> (gdb) up
> #2 0x0022de70 in ?? ()
> (gdb) info frame
> Stack level 2, frame at 0x22de6c:
> eip = 0x22de70; saved eip 0x1095a870
> called by frame at 0x22de70, caller of frame at 0x22de68
> Arglist at 0x22de64, args:
> Locals at 0x22de64, Previous frame's sp is 0x22de6c
> Saved registers:
> eip at 0x22de68
> (gdb) up
> #3 0x1095a870 in ?? ()
> (gdb) info frame
> Stack level 3, frame at 0x22de70:
> eip = 0x1095a870; saved eip 0x1c49468
> called by frame at 0x22de74, caller of frame at 0x22de6c
> Arglist at 0x22de68, args:
> Locals at 0x22de68, Previous frame's sp is 0x22de70
> Saved registers:
> eip at 0x22de6c
> (gdb) up
> #4 0x01c49468 in ?? ()
> (gdb) info frame
> Stack level 4, frame at 0x22de74:
> eip = 0x1c49468; saved eip 0x0
> caller of frame at 0x22de70
> Arglist at 0x22de6c, args:
> Locals at 0x22de6c, Previous frame's sp is 0x22de74
> Saved registers:
> eip at 0x22de70
> (gdb) up
> Initial frame selected; you cannot go up.
> (gdb) where
> #0 0x119a2170 in ?? ()
> #1 0x00000003 in ?? ()
> #2 0x0022de70 in ?? ()
> #3 0x1095a870 in ?? ()
> #4 0x01c49468 in ?? ()
> (gdb)
>
>
> =========================================================
>
>> I also usually add +RTS -Ds -RTS to the command line.
>>
>
> This produced a vast amount of information (cut off in the shortened
> example below with ^C) which included occasional messages about both
> heap and stack overflows:
>
> Starting program:
> /c/cvs/stable/i386-unknown-mingw32/ghc/compiler/stage2/ghc.exe
> -Bc:/cvs/stable/i386-unknown-mingw32 -no-recomp -dcore-lint
> -Di386_unknown_min
> gw32 hClose001.hs --interactive -v0 +RTS -Ds -RTS
> sched: created thread 1, stack size = f3 words
> sched: waiting for thread (1)
> sched: new main thread (1)
> all threads:
> thread 1 @ 00FC0000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 1 @ 00FC0000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 1 @ 00FC0000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 1 @ 00FC0000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped: is blocked on read from
> fd 4173656
> all threads:
> thread 1 @ 00FC0000 is blocked on read from fd 4173656
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 1 @ 00FC0000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 1 @ 00FC0000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped: HeapOverflow
> sched: created thread 2, stack size = f3 words
> all threads:
> thread 2 @ 01355030 is not blocked
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 is not blocked
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 2 ThreadRunGHC ...
> sched: --++ thread 2 (ThreadComplete) finished
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030 has completed
> thread 1 @ 00FB9000 is not blocked
> sched: -->> running thread 1 ThreadRunGHC ...
> sched: --<< thread 1 (ThreadRunGHC) stopped, yielding
> all threads:
> thread 2 @ 01355030
> Program received signal SIGINT, Interrupt.
> [Switching to thread 1116.0x610]
> 0x7c5b9a91 in UnregisterConsoleIME () from
> /c/WINNT/system32/KERNEL32.DLL (gdb) Quit
> (gdb) bt
> #0 0x7c5b9a91 in UnregisterConsoleIME () from
> /c/WINNT/system32/KERNEL32.DLL
> #1 0x7ffd8000 in ?? ()
> #2 0x00fcfbb4 in ?? ()
> (gdb) q
> The program is running. Exit anyway? (y or n) y
> =========================================================
More information about the Cvs-ghc
mailing list