Summary of GHC 6.6 test suite failures on MSYS/MinGW
Brian Smith
brianlsmith at gmail.com
Wed Sep 13 13:23:27 EDT 2006
I finished re-running the test suite with all the necessary libraries
installed.
Here are the tests that are failing:
make stage=2 TESTS="TH_exn TH_fail cabal01 cabal02 conc023 conc037 conc049
conc056 ffi012 ghcpkg04 maessen_hashtab readwrite002 tcfail115 tcfail140
utf8_002 utf8_003 utf8_004 utf8_005"
Of particular concern is maessen_hashtab because it segfaults during the
test.
Below is a brief description of the result of each test. For many of these
tests, I do not yet know enough to fix them. But, hopefully this report will
be helpful to somebody else.
Regards,
Brian
* maessen-hashtab
This test segfaults, dereferencing a null pointer. This happens every way
(normal,opt,optasm,prof,profasm,ghci,threaded1,threaded2) it gets run. The
error message printed is too long to repeat here. I have no idea what the
problem is.
* utf8_002, utf8_003, utf8_004, utf8_005:
These tests all fail the same way, outputing:
utf8_002.hs:2:0: lexical error at end of input
instead of:
utf8_002.hs:2:0: lexical error (UTF-8 decoding error)
* readwrite002
This program complains to stderr:
readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument
(Invalid argument)
and to stdout:
###############
Caught EOF
###############
Caught EOF
###############
Caught EOF
* TH_exn(normal)
TH_fail(normal)
These two fail because the GHC indents the pretty-printed code in the
error message differently than expected.
* conc023(ghci)
This test only fails when run via GHCi. This test runs out of memory. The
error message to stderr is:
conc023: failed to create OS thread: Not enough storage is available to
process this command.
When I came back to the computer I saw that Windows was warning me that I
was out of virtual memory and that it was increasing my page file size. I
have 1GB of RAM which I think should be sufficient to run the testsuite
successfully.
* conc037(threaded2)
This test prints the output in a different order than expected, but I don't
know enough about how Control.Concurrent is supposed to work to know if the
problem is in GHC or in the test. Please note that I am running the tests on
a dual core (Core Duo) processor:
! newThread started
! mainThread
! newThread back again
! 1 sec later
!
! shutting down
--- 1,6 ----
! mainThread
! newThread started
! newThread back again
! 1 sec later
!
! shutting down
* ffi012(ghci)
This happens only when run via GHCi. The following error message is issued
instead of the expected output:
During interactive linking, GHCi couldn't find the following symbol:
Main_d1d4
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs at haskell.org
ghcpkg04(normal)
An error message different than the expected. I didn't investigate this one
too closely:
!
! ghcpkg04.hs:1:0:
! Failed to load interface for `A':
! it was found in multiple packages: testpkg-1.2.3.4 newtestpkg-2.0
--- 1,4 ----
!
! ghcpkg04.hs:1:0:
! Failed to load interface for `A':
! Use -v to see a list of the files searched for.
* tcfail115, tcfail140
The error messages output by GHC are very different than the expected ones.
No clue as to why though.
* cabal01, cabal02
These fail because Cabal won't work when the GHC executable is actually a
shell script on Windows.
* process001, process002, prog001, prog002, prog003
These fail because they depend on executables (ls, rm) that are not
available on Windows.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20060913/e34c68c9/attachment.htm
More information about the Glasgow-haskell-bugs
mailing list