Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
Brian Smith wrote: On 9/26/06, *Simon Marlow* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Brian Smith wrote: The test always failed. When I decreased the number of threads in the test from 5,000 to 1,400 or so, then the tests passed sometimes, and sometimes failed. Decreasing the number of threads to under a thousand made the test pass consistently. IIRC, the test failed almost immediately upon executing. conc023 creates 5000 threads that all do threadDelay with varying delays. On Windows, with both the threaded and non-threaded runtimes, this results in 5000 OS threads being created, which is usually enough to fill up your VM. I intend to fix this, at least in the threaded RTS, in fact it'll be part of the fix for http://hackage.haskell.org/trac/ghc/ticket/637. The I/O manager thread handles sleeps and signals, but currently isn't implemented on Windows. It already passes in the threaded RTS and every other way except GHCi: normal, opt, optasm, prof, profasm, threaded1, and threaded2. That is what I thought was strange. It's slightly odd that the test only runs out of memory in GHCi, but I doubt there's anything GHCi-specific about the problem, just probably GHCi needs more memory full stop. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
On 9/26/06, Simon Marlow [EMAIL PROTECTED] wrote: Brian Smith wrote: Now, when I tried to rerun the tests against the latest ghc-6.6, ghc.exe is segfaulting on ffi012(ghci), conc049(ghci), and conc023(ghci): Unhandled exception at 0x0207fc58 in ghc.exe: 0xC005: Access violation.That's a bit worrying...This is caused by Data Execution Prevention. When I disable DEP for stage2/ghc.exe, these programs do not segfault; instead ff012 and conc023 fail while conc049 passes. When I enable DEP, all three segfault. http://hackage.haskell.org/trac/ghc/ticket/885 seems to be the relevant issue. I am using a Core Duo processor instead of an Athlon, but the gist is the same. The reason I did not notice this earlier was because I just turned on DEP for all programs in the days between the first time I ran the test suite against 6.6 and this most recent time. Regards,Brian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
Brian Smith wrote: On 9/25/06, *Ian Lynagh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Wed, Sep 13, 2006 at 12:23:27PM -0500, Brian Smith wrote: * 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. Does that happen repeatably? The test always failed. When I decreased the number of threads in the test from 5,000 to 1,400 or so, then the tests passed sometimes, and sometimes failed. Decreasing the number of threads to under a thousand made the test pass consistently. IIRC, the test failed almost immediately upon executing. conc023 creates 5000 threads that all do threadDelay with varying delays. On Windows, with both the threaded and non-threaded runtimes, this results in 5000 OS threads being created, which is usually enough to fill up your VM. I intend to fix this, at least in the threaded RTS, in fact it'll be part of the fix for http://hackage.haskell.org/trac/ghc/ticket/637. The I/O manager thread handles sleeps and signals, but currently isn't implemented on Windows. Now, when I tried to rerun the tests against the latest ghc-6.6, ghc.exe is segfaulting on ffi012(ghci), conc049(ghci), and conc023(ghci): Unhandled exception at 0x0207fc58 in ghc.exe: 0xC005: Access violation. That's a bit worrying... Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
On 9/26/06, Simon Marlow [EMAIL PROTECTED] wrote: Brian Smith wrote: The test always failed. When I decreased the number of threads in the test from 5,000 to 1,400 or so, then the tests passed sometimes, and sometimes failed. Decreasing the number of threads to under a thousand made the test pass consistently. IIRC, the test failed almost immediately upon executing.conc023 creates 5000 threads that all do threadDelay with varying delays.On Windows, with both the threaded and non-threaded runtimes, this results in 5000 OS threads being created, which is usually enough to fill up your VM. I intend to fix this, at least in the threaded RTS, in fact it'll be part of the fix for http://hackage.haskell.org/trac/ghc/ticket/637.The I/O manager threadhandles sleeps and signals, but currently isn't implemented on Windows. It already passes in the threaded RTS and every other way except GHCi: normal, opt, optasm, prof, profasm, threaded1, and threaded2. That is what I thought was strange.Regards,Brian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
On Wed, Sep 13, 2006 at 12:23:27PM -0500, Brian Smith wrote: I finished re-running the test suite with all the necessary libraries installed. Cool, thanks! * 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) This is just due to different alex's giving different errors. * 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. Does that happen repeatably? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Summary of GHC 6.6 test suite failures on MSYS/MinGW
Dont worry about Maessen_hashtab. It fails core Lint, and its on my list to look at. (Its been failing for some time) S From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Smith Sent: 13 September 2006 18:23 To: glasgow-haskell-bugs@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@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
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-hashtabThis 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 inputinstead of: utf8_002.hs:2:0: lexical error (UTF-8 decoding error) * readwrite002This 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_d1d4This 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 -lmissinglibnameflags, 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, tcfail140The error messages output by GHC are very different than the expected ones. No clue as to why though. * cabal01, cabal02These fail because Cabal won't work when the GHC executable is actually a shell script on Windows.* process001, process002, prog001, prog002, prog003These 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
Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW
On Wed, Sep 13, 2006 at 12:23:27PM -0500, Brian Smith wrote: 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 The following aren't Windows problems, because they're failing in the nightly builds of both i386-unknown-linux and x86_64-unknown-linux: TH_exn(normal) TH_fail(normal) maessen_hashtab(normal,opt,optasm,prof,profasm,unreg,ghci,threaded1,threaded 2) tcfail115(normal) tcfail140(normal) ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
