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@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.

_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to