Summary of GHC 6.6 test suite failures on MSYS/MinGW

[Simon Peyton-Jones]

Don't worry about Maessen_hashtab. It fails core Lint, and it's on my
list to look at.  (It's been failing for some time...)

 

S

 

________________________________

From: glasgow-haskell-bugs-bounces at haskell.org
[mailto:glasgow-haskell-bugs-bounces at haskell.org] On Behalf Of Brian
Smith
Sent: 13 September 2006 18:23
To: glasgow-haskell-bugs at haskell.org
Subject: Summary of GHC 6.6 test suite failures on MSYS/MinGW

 

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/20060918/ca754d6b/attachment.htm