Re: Windows test failures
forgot to copy in ghc-devs. On Fri, Dec 7, 2018 at 12:05 AM Phyx wrote: > Ah great, > > Normally an msys2 .profile will contain the following line > > # Set user-defined locale > export LANG=$(locale -uU) > > which would attach ".UTF-8" to the user's current locale. > I'm guessing when you run it from emacs the profile isn't loaded (probably > because bash isn't being called with --login) or something in bashrc or > profile is overwriting this. > > Setting this should bring the test failures down more. > > Which leaves only these tests > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-impure.runplugin-recomp-impure > [bad exit code] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad > exit code] (normal) > > as the remaining unexplained ones. > > Do these still fail for you? > > Cheers, > Tamar > > > On Thu, Dec 6, 2018 at 11:50 PM Simon Peyton Jones > wrote: > >> Aha! Yes, in libraries/base/tests, I find that make TEST=T3307 fails; >> but succeeds with >> >> >> >> export LANG=en_GB.UTF-8 >> >> >> >> Progress! >> >> >> >> Simon >> >> >> >> *From:* Phyx >> *Sent:* 06 December 2018 23:43 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs@haskell.org Devs >> *Subject:* Re: Windows test failures >> >> >> >> Hi Simon, >> >> >> >> > Does that help at all? >> >> > >> >> > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test >> its efficacy by running one test rather than 6,000 of them? In which case, >> which one? >> >> >> >> Yes, "en_GB" doesn't seem to be a unicode locale, one test you can try to >> check is T3307,so make TEST="T3307" -C testsuite/tests/ >> >> >> >> I tried using your "en_GB" locale and the test failed for me too then. >> >> >> >> Kind regards, >> >> Tamar >> >> >> >> On Thu, Dec 6, 2018 at 2:17 PM Simon Peyton Jones >> wrote: >> >> Hi Tamar >> >> >> >> Thanks for working on this. >> >> >> >> if it's an msys2 shell, what does "locale" return? >> >> >> >> It’s a shell running inside emacs. Here’s what locale returns >> >> /c/tmp$ locale >> >> LANG=en_GB >> >> LC_CTYPE="en_GB" >> >> LC_NUMERIC="en_GB" >> >> LC_TIME="en_GB" >> >> LC_COLLATE="en_GB" >> >> LC_MONETARY="en_GB" >> >> LC_MESSAGES="en_GB" >> >> LC_ALL= >> >> >> >> Does that help at all? >> >> >> >> I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test >> its efficacy by running one test rather than 6,000 of them? In which case, >> which one? >> >> >> Thanks >> >> >> >> Simon >> >> >> >> >> >> *From:* Phyx >> *Sent:* 02 December 2018 20:43 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs@haskell.org Devs >> *Subject:* Re: Windows test failures >> >> >> >> Hi Simon, >> >> >> >> That's a bit better (still need to figure out why the recent threading >> issues, but one problem at a time :) ) >> >> >> >> From that list T10672_x64 is one I'm looking at already, seems to have >> something to do with the libstdc++ destructors. >> >> Plugins 09 and 10 are the other two I know about, but haven't had time to >> look at them yet. Frankly I know too little about plugins to make an >> accurate determination here, but the input files are empty >> >> yet it expects output, so I don't know what it's supposed to do here. If >> someone who knows more about plugins can chime in that would save some time. >> >> >> >> The segfaulting plugin I haven't triaged yet. Now the remaining failures >> aside from T14452 that Roland is taking care of, seem to have to do with >> your locale in your console. You seem to be running the >> >> tests in a console that has l
Re: Windows test failures
Hi Roland,
Thanks for looking into thiis,
> To fix the issue on Windows, the compiler and the plugin should use the
same buffer for stdout.
I'm not convinced that they're not. I'm guessing the answer lies in why
your messages have a different
ordering, but I don't know why off the top of my head.
if the plugins use the stdout caf then it should be using the same
CharBuffer.
You can verify this by doing something like
cbuf <- readIORef haCharBuffer stdout
summaryBuffer cbuf
putStrLn $ "buffer: " ++ show cbuf
at the places you check the buffer mode.
> However I don't know whether this is possible / difficult / easy?
> What's your opinion?
On Tue, Dec 4, 2018 at 11:52 AM Roland Senn wrote:
> Hi Tamar,
>
> WINDOWS
> ===
> On Windows I did the following changes before running the 'plugin09' test:
> 1.) In the compiler (HscMain.hs), just before calling the plugin function
> 'parsedPlugin', I set BufferMode of the file stdout to LineBuffering.
> 2.) At the same place, I write a message to stdout with the text "COMPILER
> About to call plugin parse" and the result of the buffer-mode query.
> 3.) In the plugin, in the function parsedPlugin, I query and print (to
> stdout) the buffer mode.
> 4.) I added the heading PLUGIN to the normal parse message issued by the
> parsedPlugin function
> 5.) In the compiler (HscMain.hs) just after returning from the plugin, I
> print the line "COMPILER Returning from plugin parse" to stdout.
> 6.) In the plugin function interfaceLoadPlugin' that is called much
> later, I flush stdout, and add the heading "PLUGIN".
>
> This gives the following interesting result:
>
> COMPILER About to call plugin parse: LineBuffering
> COMPILER Returning from plugin parse
> PLUGIN Buffermode: BlockBuffering Nothing
> PLUGIN parsePlugin(a,b)
> PLUGIN interfacePlugin: Prelude
> ...
>
> The output lines do not appear in the sequence they were produced!!
> The plugin doesn't see/inherit the BlockBuffer mode (LineBuffering) set by
> the compiler!!
>
> This is a strong indication, that *there are two different buffers for
> stdout*. One in the compiler and another one in the plugin.
> At the end of the processing, the buffer in the compiler is automatically
> flushed, however the buffer in the plugin never gets flushed!
>
> LINUX
> =
> I did a similar test in Linux, however, here I set the buffer mode to
> 'Blockmode Nothing' and I didn't do a manual flush in the plugin. I got the
> following result:
>
> COMPILER About to call plugin parse: Buffering mode: BlockBuffering
> Nothing
> PLUGIN Buffering: BlockBuffering Nothing
> PLUGIN parsePlugin(a,b)
> COMPILER Returning from plugin parse
> PLUGIN interfacePlugin: Prelude
> ...
>
> Here the lines are in the same order as they were produced.
> The setting of the Buffering mode is inherited by the plugin.
>
> I think, on Linux the compiler and the plugin share the same buffer.
>
> To fix the issue on Windows, the compiler and the plugin should use the
> same buffer for stdout.
> However I don't know whether this is possible / difficult / easy?
> What's your opinion?
>
> Many thanks and kind regards
>Roland
>
> Here are my changes for Windows in code:
>
> Change in HscMain the line "import System.IO (fixIO)" to "import System.IO
> "
>
> Last lines of function HscMain.hs:hscParse'
>
> -- apply parse transformation of plugins
> let applyPluginAction p opts
> = parsedResultAction p opts mod_summary
> liftIO $ hSetBuffering stdout LineBuffering
> mode <- liftIO $ hGetBuffering stdout
> liftIO $ putStrLn ("COMPILER About to call plugin parse: " ++
> show mode)
> rsxresult <- withPlugins dflags applyPluginAction res
> liftIO $ putStrLn "COMPILER Returning from plugin parse"
> return rsxresult
>
> New code for function SourcePlugin.hs:parsedPlugin
>
> parsedPlugin opts _ pm
> = do
>mode <- liftIO $ hGetBuffering stdout
>liftIO $ putStrLn $ "PLUGIN Buffermode: " ++ show mode
>liftIO $ putStrLn $ "PLUGIN parsePlugin(" ++ intercalate "," opts
> ++ ")"
>return pm
>
> New code for function SourcePlugin.hs:interfaceLoadPlugin'
>
> interfaceLoadPlugin' :: [CommandLineOption] -> ModIface -> IfM lcl ModIface
> interfaceLoadPlugin' _ iface
> = do liftIO $ putStrLn $ "PLUGIN interfacePlugin: "
> ++ (showSDocUnsafe $ ppr $ mi_module iface)
>liftIO $ hFlush stdout
>return iface
>
>
>
> Am Dienstag, den 04.12.2018, 00:02 + schrieb Phyx:
>
> Hi Roland,
>
> Thanks for looking into these.
>
> > I looked into the testcases 'plugins09', 'plugins10' and 'plugins11' and
> found the following: GHC-Windows uses BufferMode 'BlockBuffering Nothing',
> however, GHC-Linux uses 'LineBuffering'.
>
> Ah, yes, this isn't technically a Linux vs Windows thing, GHC will always
> default to LineBuffering for terminals and BlockBuffering for anything
> else. The issue is
Re: Windows test failures
Hi Simon, > Does that help at all? > > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test its efficacy by running one test rather than 6,000 of them? In which case, which one? Yes, "en_GB" doesn't seem to be a unicode locale, one test you can try to check is T3307,so make TEST="T3307" -C testsuite/tests/ I tried using your "en_GB" locale and the test failed for me too then. Kind regards, Tamar On Thu, Dec 6, 2018 at 2:17 PM Simon Peyton Jones wrote: > Hi Tamar > > > > Thanks for working on this. > > > > if it's an msys2 shell, what does "locale" return? > > > > It’s a shell running inside emacs. Here’s what locale returns > > /c/tmp$ locale > > LANG=en_GB > > LC_CTYPE="en_GB" > > LC_NUMERIC="en_GB" > > LC_TIME="en_GB" > > LC_COLLATE="en_GB" > > LC_MONETARY="en_GB" > > LC_MESSAGES="en_GB" > > LC_ALL= > > > > Does that help at all? > > > > I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test > its efficacy by running one test rather than 6,000 of them? In which case, > which one? > > > Thanks > > > > Simon > > > > > > *From:* Phyx > *Sent:* 02 December 2018 20:43 > *To:* Simon Peyton Jones > *Cc:* ghc-devs@haskell.org Devs > *Subject:* Re: Windows test failures > > > > Hi Simon, > > > > That's a bit better (still need to figure out why the recent threading > issues, but one problem at a time :) ) > > > > From that list T10672_x64 is one I'm looking at already, seems to have > something to do with the libstdc++ destructors. > > Plugins 09 and 10 are the other two I know about, but haven't had time to > look at them yet. Frankly I know too little about plugins to make an > accurate determination here, but the input files are empty > > yet it expects output, so I don't know what it's supposed to do here. If > someone who knows more about plugins can chime in that would save some time. > > > > The segfaulting plugin I haven't triaged yet. Now the remaining failures > aside from T14452 that Roland is taking care of, seem to have to do with > your locale in your console. You seem to be running the > > tests in a console that has latin-1 locale? So some unicode characters > fail encoding/decoding. > > > > If it's a Windows shell you can change it to utf-8 using "chcp 65001", if > it's an msys2 shell, what does "locale" return? > > > > For reference mine is > > > > $ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_ALL= > > > > If it does say latin1 you can change it with > > > > export LANG=en_GB.UTF-8 > > > > This should fix more of the tests. > > > > The reason I don't mark the remaining tests as expect fail yet is because > I haven't had the time to triage them, so I don't know their severity and > > last time there were a few nasty issues hidden in them. > > > > Unfortunately I won't have time to look at them till next weekend. > > > > Thanks, > > Tamar > > > > On Fri, Nov 30, 2018 at 9:49 PM Simon Peyton Jones > wrote: > > At the end of the first test run it would have given a list of tests that > failed and a line saying TEST=" List of tests..." > > > > Copy that line and at the root of the checkout do > > > > make TEST=" List of tests..." test -C testsuite/tests > > > > (that's uppercase C). This will run everything using one thread. :) > > > > OK, done. Results below. > > > > Simon > > > > > > /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 > T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change > plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 > plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C > testsuite/tests > > make: Entering directory '/c/code/HEAD/testsuite/tests' > > PYTHON="python3" "python3" ../driver/runtests.py -e > "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output'&
RE: Windows test failures
Hi Tamar Thanks for working on this. if it's an msys2 shell, what does "locale" return? It’s a shell running inside emacs. Here’s what locale returns /c/tmp$ locale LANG=en_GB LC_CTYPE="en_GB" LC_NUMERIC="en_GB" LC_TIME="en_GB" LC_COLLATE="en_GB" LC_MONETARY="en_GB" LC_MESSAGES="en_GB" LC_ALL= Does that help at all? I can try your “export LANG=en_GB.UTF-8” … shall I do that? Can I test its efficacy by running one test rather than 6,000 of them? In which case, which one? Thanks Simon From: Phyx Sent: 02 December 2018 20:43 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Devs Subject: Re: Windows test failures Hi Simon, That's a bit better (still need to figure out why the recent threading issues, but one problem at a time :) ) From that list T10672_x64 is one I'm looking at already, seems to have something to do with the libstdc++ destructors. Plugins 09 and 10 are the other two I know about, but haven't had time to look at them yet. Frankly I know too little about plugins to make an accurate determination here, but the input files are empty yet it expects output, so I don't know what it's supposed to do here. If someone who knows more about plugins can chime in that would save some time. The segfaulting plugin I haven't triaged yet. Now the remaining failures aside from T14452 that Roland is taking care of, seem to have to do with your locale in your console. You seem to be running the tests in a console that has latin-1 locale? So some unicode characters fail encoding/decoding. If it's a Windows shell you can change it to utf-8 using "chcp 65001", if it's an msys2 shell, what does "locale" return? For reference mine is $ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_ALL= If it does say latin1 you can change it with export LANG=en_GB.UTF-8 This should fix more of the tests. The reason I don't mark the remaining tests as expect fail yet is because I haven't had the time to triage them, so I don't know their severity and last time there were a few nasty issues hidden in them. Unfortunately I won't have time to look at them till next weekend. Thanks, Tamar On Fri, Nov 30, 2018 at 9:49 PM Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: At the end of the first test run it would have given a list of tests that failed and a line saying TEST=" List of tests..." Copy that line and at the root of the checkout do make TEST=" List of tests..." test -C testsuite/tests (that's uppercase C). This will run everything using one thread. :) OK, done. Results below. Simon /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C testsuite/tests make: Entering directory '/c/code/HEAD/testsuite/tests' PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=True -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e config.have_interp=True -e config.unregisterised=False -e config.have_gdb=False -e config.have_readelf=True -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --config-file=../config/ghc -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config
Re: Windows test failures
Hi Tamar,
WINDOWS===On Windows I did the following changes before running the
'plugin09' test: 1.) In the compiler (HscMain.hs), just before calling
the plugin function 'parsedPlugin', I set BufferMode of the file stdout
to LineBuffering. 2.) At the same place, I write a message to stdout
with the text "COMPILER About to call plugin parse" and the result of
the buffer-mode query. 3.) In the plugin, in the function parsedPlugin,
I query and print (to stdout) the buffer mode. 4.) I added the heading
PLUGIN to the normal parse message issued by the parsedPlugin function
5.) In the compiler (HscMain.hs) just after returning from the plugin,
I print the line "COMPILER Returning from plugin parse" to stdout. 6.)
In the plugin function interfaceLoadPlugin' that is called much later,
I flush stdout, and add the heading "PLUGIN".
This gives the following interesting result:
COMPILER About to call plugin parse: LineBuffering COMPILER Returning
from plugin parse PLUGIN Buffermode: BlockBuffering Nothing PLUGIN
parsePlugin(a,b) PLUGIN interfacePlugin: Prelude ...
The output lines do not appear in the sequence they were produced!!The
plugin doesn't see/inherit the BlockBuffer mode (LineBuffering) set by
the compiler!!
This is a strong indication, that there are two different buffers for
stdout. One in the compiler and another one in the plugin.At the end of
the processing, the buffer in the compiler is automatically flushed,
however the buffer in the plugin never gets flushed!
LINUX=I did a similar test in Linux, however, here I set the buffer
mode to 'Blockmode Nothing' and I didn't do a manual flush in the
plugin. I got the following result:
COMPILER About to call plugin parse: Buffering mode: BlockBuffering
Nothing PLUGIN Buffering: BlockBuffering Nothing PLUGIN
parsePlugin(a,b) COMPILER Returning from plugin parse PLUGIN
interfacePlugin: Prelude ...
Here the lines are in the same order as they were produced.The setting
of the Buffering mode is inherited by the plugin.
I think, on Linux the compiler and the plugin share the same buffer.
To fix the issue on Windows, the compiler and the plugin should use the
same buffer for stdout.However I don't know whether this is possible /
difficult / easy?What's your opinion?
Many thanks and kind regards Roland
Here are my changes for Windows in code:
Change in HscMain the line "import System.IO (fixIO)" to "import
System.IO"
Last lines of function HscMain.hs:hscParse'
-- apply parse transformation of pluginslet
applyPluginAction p opts = parsedResultAction p opts
mod_summaryliftIO $ hSetBuffering stdout
LineBufferingmode <- liftIO $ hGetBuffering
stdoutliftIO $ putStrLn ("COMPILER About to call plugin
parse: " ++ show mode)rsxresult <- withPlugins dflags
applyPluginAction resliftIO $ putStrLn "COMPILER Returning
from plugin parse"return rsxresult
New code for function SourcePlugin.hs:parsedPlugin
parsedPlugin opts _ pm = do mode <- liftIO $ hGetBuffering
stdout liftIO $ putStrLn $ "PLUGIN Buffermode: " ++ show
mode liftIO $ putStrLn $ "PLUGIN parsePlugin(" ++ intercalate ","
opts ++ ")" return pm
New code for function SourcePlugin.hs:interfaceLoadPlugin'
interfaceLoadPlugin' :: [CommandLineOption] -> ModIface -> IfM lcl
ModIfaceinterfaceLoadPlugin' _ iface = do liftIO $ putStrLn $ "PLUGIN
interfacePlugin: " ++ (showSDocUnsafe $
ppr $ mi_module iface) liftIO $ hFlush stdout return iface
Am Dienstag, den 04.12.2018, 00:02 + schrieb Phyx:
> Hi Roland,
>
> Thanks for looking into these.
>
> >
> I looked into the testcases 'plugins09', 'plugins10' and 'plugins11'
> and
> found the following: GHC-Windows uses BufferMode 'BlockBuffering
> Nothing', however, GHC-Linux uses 'LineBuffering'.
>
> Ah, yes, this isn't technically a Linux vs Windows thing, GHC will
> always default to LineBuffering for terminals and BlockBuffering for
> anything else. The issue is that msys2 terminals have std handles
> that are backed by files instead of pipes. This is an artifact of how
> they try to emulate posix shells, See https://github.com/msys2/msys2/
> wiki/Porting#standard-streams-in-mintty.
> This means that when GHC runs inside an msys2 program such as bash
> it'll always default to BlockBuffering.
>
>
>
> >
> I don't know anything about the "Why" and "Where" in the GHC IO
> module on Windows, so I'm unable to come up with a patch.
>
> The above said the handles should be getting flushed when the
> finalizers are run, but these aren't 100% guaranteed so if the tests
> rely on this then your solution (to force buffer mode to
> LineBuffering) sounds like perfectly adequate. Could you put a patch
> up with that?
>
> My new I/O manager takes a different approach to determine the buffer
> mode, but I still have some kinks to work out before posting it.
>
> >
> PS: I can't say anything a
Re: Windows test failures
Hi Roland, Thanks for looking into these. > I looked into the testcases 'plugins09', 'plugins10' and 'plugins11' and found the following: GHC-Windows uses BufferMode 'BlockBuffering Nothing', however, GHC-Linux uses 'LineBuffering'. Ah, yes, this isn't technically a Linux vs Windows thing, GHC will always default to LineBuffering for terminals and BlockBuffering for anything else. The issue is that msys2 terminals have std handles that are backed by files instead of pipes. This is an artifact of how they try to emulate posix shells, See https://github.com/msys2/msys2/wiki/Porting#standard-streams-in-mintty. This means that when GHC runs inside an msys2 program such as bash it'll always default to BlockBuffering. > I don't know anything about the "Why" and "Where" in the GHC IO module on Windows, so I'm unable to come up with a patch. The above said the handles should be getting flushed when the finalizers are run, but these aren't 100% guaranteed so if the tests rely on this then your solution (to force buffer mode to LineBuffering) sounds like perfectly adequate. Could you put a patch up with that? My new I/O manager takes a different approach to determine the buffer mode, but I still have some kinks to work out before posting it. > PS: I can't say anything about the tests 'plugin-recomp-pure' and 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows box. These don't fail for me or harbormaster either, so if Simon is able to consistently reproduce these then I'll have to ask him for a core dump so I can take a look. Thanks again, I appreciate the help! Regards, Tamar On Mon, Dec 3, 2018 at 3:34 PM Roland Senn wrote: > Hi Tamar, > > I looked into the testcases 'plugins09', 'plugins10' and 'plugins11' and > found the following: GHC-Windows uses BufferMode 'BlockBuffering Nothing', > however, GHC-Linux uses 'LineBuffering'. > > If I add an 'import System.IO' and the line 'liftIO $ hSetBuffering stdout > LineBuffer' as first line in the do block of the function > '.../testuite/tests/plugins/simple-plugin/Simple/SourcePlugin.hs:parsedPlugin' > then all 3 tests pass successfully on Windows! > > I don't know anything about the "Why" and "Where" in the GHC IO module on > Windows, so I'm unable to come up with a patch. > > Regards >Roland > > PS: I can't say anything about the tests 'plugin-recomp-pure' and > 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows > box. > > Am Sonntag, den 02.12.2018, 20:42 + schrieb Phyx: > > Hi Simon, > > That's a bit better (still need to figure out why the recent threading > issues, but one problem at a time :) ) > > From that list T10672_x64 is one I'm looking at already, seems to have > something to do with the libstdc++ destructors. > Plugins 09 and 10 are the other two I know about, but haven't had time to > look at them yet. Frankly I know too little about plugins to make an > accurate determination here, but the input files are empty > yet it expects output, so I don't know what it's supposed to do here. If > someone who knows more about plugins can chime in that would save some time. > > The segfaulting plugin I haven't triaged yet. Now the remaining failures > aside from T14452 that Roland is taking care of, seem to have to do with > your locale in your console. You seem to be running the > tests in a console that has latin-1 locale? So some unicode characters > fail encoding/decoding. > > If it's a Windows shell you can change it to utf-8 using "chcp 65001", if > it's an msys2 shell, what does "locale" return? > > For reference mine is > > $ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_ALL= > > If it does say latin1 you can change it with > > export LANG=en_GB.UTF-8 > > This should fix more of the tests. > > The reason I don't mark the remaining tests as expect fail yet is because > I haven't had the time to triage them, so I don't know their severity and > last time there were a few nasty issues hidden in them. > > Unfortunately I won't have time to look at them till next weekend. > > Thanks, > Tamar > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows test failures
Hi Tamar, I looked into the testcases 'plugins09', 'plugins10' and 'plugins11' and found the following: GHC-Windows uses BufferMode 'BlockBuffering Nothing', however, GHC-Linux uses 'LineBuffering'. If I add an 'import System.IO' and the line 'liftIO $ hSetBuffering stdout LineBuffer' as first line in the do block of the function '.../testuite/tests/plugins/simple- plugin/Simple/SourcePlugin.hs:parsedPlugin' then all 3 tests pass successfully on Windows! I don't know anything about the "Why" and "Where" in the GHC IO module on Windows, so I'm unable to come up with a patch. Regards Roland PS: I can't say anything about the tests 'plugin-recomp-pure' and 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows box. Am Sonntag, den 02.12.2018, 20:42 + schrieb Phyx: > Hi Simon, > > That's a bit better (still need to figure out why the recent > threading issues, but one problem at a time :) ) > > From that list T10672_x64 is one I'm looking at already, seems to > have something to do with the libstdc++ destructors. > Plugins 09 and 10 are the other two I know about, but haven't had > time to look at them yet. Frankly I know too little about plugins to > make an accurate determination here, but the input files are empty > yet it expects output, so I don't know what it's supposed to do > here. If someone who knows more about plugins can chime in that > would save some time. > > The segfaulting plugin I haven't triaged yet. Now the remaining > failures aside from T14452 that Roland is taking care of, seem to > have to do with your locale in your console. You seem to be running > the > tests in a console that has latin-1 locale? So some unicode > characters fail encoding/decoding. > > If it's a Windows shell you can change it to utf-8 using "chcp > 65001", if it's an msys2 shell, what does "locale" return? > > For reference mine is > > $ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_ALL= > > If it does say latin1 you can change it with > > export > LANG=en_GB.UTF-8 > > This should fix more of the tests. > > The reason I don't mark the remaining tests as expect fail yet is > because I haven't had the time to triage them, so I don't know their > severity and > last time there were a few nasty issues hidden in them. > > Unfortunately I won't have time to look at them till next weekend. > > Thanks, > Tamar > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows test failures
recomp-pure(normal) 19 of 21 [0, 7, 1] > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory > plugin-recomp-pure > > Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && > $MAKE -s --no-print-directory plugin-recomp-pure "... > > > > Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) > > Stdout ( plugin-recomp-pure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Stderr ( plugin-recomp-pure ): > > Simple Plugin Passes Queried > > Got options: > > Simple Plugin Pass Run > > *** unexpected failure for plugin-recomp-pure(normal) > > => plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory > plugin-recomp-impure > > Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) > > Stdout ( plugin-recomp-impure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Linking plugin-recomp-test.exe ... > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) [Plugin forced recompilation] > > Stderr ( plugin-recomp-impure ): > > Simple Plugin Passes Queried > > Got options: > > Simple Plugin Pass Run > > Simple Plugin Passes Queried > > Access violation in generated code when reading 0xa824 > > > > Attempting to reconstruct a stack trace... > > > >Frame Code address > > * 0x49adab0 0x1eb49ec C:\code\HEAD\inplace\bin\ghc-stage2.exe+0x1ab49ec > > > > make[1]: *** [Makefile:99: plugin-recomp-impure] Error 11 > > *** unexpected failure for plugin-recomp-impure(normal) > > => plugin-recomp-flags(normal) 21 of 21 [0, 9, 1] > > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory > plugin-recomp-flags > > Traceback (most recent call last): > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in > test_common_work > > do_test(name, way, func, args, files) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test > > result = func(*[name,way] + args) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command > > return simple_run( name, '', override_options(cmd), '' ) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run > > dump_stderr(name) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in > dump_stderr > > print(str) > > UnicodeEncodeError: 'latin-1' codec can't encode characters in position > 24-25: ordinal not in range(256) > > > > Unexpected results from: > > TEST="T10672_x64 T14452 T3307 T4006 environment001 plugin-recomp-impure > plugin-recomp-pure plugins09 plugins10 plugins11" > > > > SUMMARY for test run started at Fri Nov 30 21:07:17 2018 GMTST > > 0:26:45 spent to go through > > 21 total tests, which gave rise to > > 36 test cases, of which > > 11 were skipped > > > >0 had missing libraries > > 15 expected passes > >0 expected failures > > > >1 caused framework failures > >0 caused framework warnings > >0 unexpected passes > >9 unexpected failures > >0 unexpected stat failures > > > > Unexpected failures: > >driver/T14452.run T14452 [bad stdout] (normal) > >rts/T10672/T10672_x64.run T10672_x64 [bad exit code] > (normal) > >libraries/base/tests/T4006.run T4006 [bad stdout] (normal) > >libraries/base/tests/IO/environment001.run environment001 [bad stdout] > (normal) > >plugins/plugins09.run plugins09 [bad stdout] > (normal) > >plugins/plugins10.run plugins10 [bad stdout] > (normal) > >plugins/plugins11.run plugins11 [bad exit code] > (normal)
Re: Windows test failures
gt; > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 > > Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s > --no-print-directory plugins11 "... > > > > Wrong exit code for plugins11()(expected 0 , actual 99 ) > > *** unexpected failure for plugins11(normal) > > => plugins13(normal) 16 of 21 [0, 7, 1] > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 > > => plugins14(normal) 17 of 21 [0, 7, 1] > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C > simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 > > => T10420(normal) 18 of 21 [0, 7, 1] > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite > > cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 > > => plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory > plugin-recomp-pure > > Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && > $MAKE -s --no-print-directory plugin-recomp-pure "... > > > > Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) > > Stdout ( plugin-recomp-pure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Stderr ( plugin-recomp-pure ): > > Simple Plugin Passes Queried > > Got options: > > Simple Plugin Pass Run > > *** unexpected failure for plugin-recomp-pure(normal) > > => plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory > plugin-recomp-impure > > Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) > > Stdout ( plugin-recomp-impure ): > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) > > Linking plugin-recomp-test.exe ... > > [1 of 1] Compiling Main ( plugin-recomp-test.hs, > plugin-recomp-test.o ) [Plugin forced recompilation] > > Stderr ( plugin-recomp-impure ): > > Simple Plugin Passes Queried > > Got options: > > Simple Plugin Pass Run > > Simple Plugin Passes Queried > > Access violation in generated code when reading 0xa824 > > > > Attempting to reconstruct a stack trace... > > > >Frame Code address > > * 0x49adab0 0x1eb49ec C:\code\HEAD\inplace\bin\ghc-stage2.exe+0x1ab49ec > > > > make[1]: *** [Makefile:99: plugin-recomp-impure] Error 11 > > *** unexpected failure for plugin-recomp-impure(normal) > > => plugin-recomp-flags(normal) 21 of 21 [0, 9, 1] > > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite > > cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory > plugin-recomp-flags > > Traceback (most recent call last): > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in > test_common_work > > do_test(name, way, func, args, files) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test > > result = func(*[name,way] + args) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command > > return simple_run( name, '', override_options(cmd), '' ) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run > > dump_stderr(name) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in > dump_stderr > > print(str) > > UnicodeEncodeError: 'latin-1' codec can't encode characters in position > 24-25: ordinal not in r
Re: Windows test failures
( plugin-recomp-test.hs, plugin-
> recomp-test.o )
> Stderr ( plugin-recomp-pure ):
> Simple Plugin Passes Queried
> Got options:
> Simple Plugin Pass Run
> *** unexpected failure for plugin-recomp-pure(normal)
> => plugin-recomp-impure(normal) 20 of 21 [0, 8, 1]
> cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-
> directory -C plugin-recomp package.plugins01
> TOP=/c/code/HEAD/testsuite
> cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-
> directory plugin-recomp-impure
>
> Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 )
> Stdout ( plugin-recomp-impure ):
> [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-
> recomp-test.o )
> Linking plugin-recomp-test.exe ...
> [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-
> recomp-test.o ) [Plugin forced recompilation]
> Stderr ( plugin-recomp-impure ):
> Simple Plugin Passes Queried
> Got options:
> Simple Plugin Pass Run
> Simple Plugin Passes Queried
> Access violation in generated code when reading 0xa824
>
> Attempting to reconstruct a stack trace...
>
> Frame Code address
> * 0x49adab0 0x1eb49ec C:\code\HEAD\inplace\bin\ghc-
> stage2.exe+0x1ab49ec
>
> make[1]: *** [Makefile:99: plugin-recomp-impure] Error 11
> *** unexpected failure for plugin-recomp-impure(normal)
> => plugin-recomp-flags(normal) 21 of 21 [0, 9, 1]
> cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory
> -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite
> cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory
> plugin-recomp-flags
>
> Traceback (most recent call last):
> File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in
> test_common_work
> do_test(name, way, func, args, files)
> File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in
> do_test
> result = func(*[name,way] + args)
> File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in
> run_command
> return simple_run( name, '', override_options(cmd), '' )
> File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in
> simple_run
> dump_stderr(name)
> File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in
> dump_stderr
> print(str)
> UnicodeEncodeError: 'latin-1' codec can't encode characters in
> position 24-25: ordinal not in range(256)
>
> Unexpected results from:
> TEST="T10672_x64 T14452 T3307 T4006 environment001 plugin-recomp-
> impure plugin-recomp-pure plugins09 plugins10 plugins11"
>
> SUMMARY for test run started at Fri Nov 30 21:07:17 2018 GMTST
> 0:26:45 spent to go through
> 21 total tests, which gave rise to
> 36 test cases, of which
> 11 were skipped
>
> 0 had missing libraries
> 15 expected passes
> 0 expected failures
>
> 1 caused framework failures
> 0 caused framework warnings
> 0 unexpected passes
> 9 unexpected failures
> 0 unexpected stat failures
>
> Unexpected failures:
> driver/T14452.run T14452 [bad stdout]
> (normal)
> rts/T10672/T10672_x64.run T10672_x64 [bad exit
> code] (normal)
> libraries/base/tests/T4006.run T4006 [bad stdout]
> (normal)
> libraries/base/tests/IO/environment001.run environment001 [bad
> stdout] (normal)
> plugins/plugins09.run plugins09 [bad stdout]
> (normal)
> plugins/plugins10.run plugins10 [bad stdout]
> (normal)
> plugins/plugins11.run plugins11 [bad exit
> code] (normal)
> plugins/plugin-recomp-pure.run plugin-recomp-pure
> [bad exit code] (normal)
> plugins/plugin-recomp-impure.run plugin-recomp-impure
> [bad exit code] (normal)
>
> Framework failures:
> libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec
> can't encode characters in position 24-25: ordinal not in range(256))
>
> Appending 0 stats to git notes.
> make: *** [../mk/test.mk:342: test] Error 1
> make: Leaving directory '/c/code/HEAD/testsuite/tests'
> /c/code/HEAD$
>
>
>
>
>
> From: Phyx
>
>
> Sent: 30 November 2018 11:58
>
> To: Simon Peyton Jones
>
> Subject: Re: Windows test failures
>
>
>
> At the end of the first test run it would have given a list of tests
> that failed and a line saying TEST=" List of tests..."
>
>
RE: Windows test failures
ame, '', override_options(cmd), '' )
File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run
dump_stderr(name)
File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in dump_stderr
print(str)
UnicodeEncodeError: 'latin-1' codec can't encode characters in position 24-25:
ordinal not in range(256)
Unexpected results from:
TEST="T10672_x64 T14452 T3307 T4006 environment001 plugin-recomp-impure
plugin-recomp-pure plugins09 plugins10 plugins11"
SUMMARY for test run started at Fri Nov 30 21:07:17 2018 GMTST
0:26:45 spent to go through
21 total tests, which gave rise to
36 test cases, of which
11 were skipped
0 had missing libraries
15 expected passes
0 expected failures
1 caused framework failures
0 caused framework warnings
0 unexpected passes
9 unexpected failures
0 unexpected stat failures
Unexpected failures:
driver/T14452.run T14452 [bad stdout] (normal)
rts/T10672/T10672_x64.run T10672_x64 [bad exit code]
(normal)
libraries/base/tests/T4006.run T4006 [bad stdout] (normal)
libraries/base/tests/IO/environment001.run environment001 [bad stdout]
(normal)
plugins/plugins09.run plugins09 [bad stdout] (normal)
plugins/plugins10.run plugins10 [bad stdout] (normal)
plugins/plugins11.run plugins11 [bad exit code]
(normal)
plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit
code] (normal)
plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit
code] (normal)
Framework failures:
libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't
encode characters in position 24-25: ordinal not in range(256))
Appending 0 stats to git notes.
make: *** [../mk/test.mk:342: test] Error 1
make: Leaving directory '/c/code/HEAD/testsuite/tests'
/c/code/HEAD$
From: Phyx
Sent: 30 November 2018 11:58
To: Simon Peyton Jones
Subject: Re: Windows test failures
At the end of the first test run it would have given a list of tests that
failed and a line saying TEST=" List of tests..."
Copy that line and at the root of the checkout do
make TEST=" List of tests..." test -C testsuite/tests
(that's uppercase C). This will run everything using one thread. :)
Should give a good starting point as to what's wrong.
Kind regards,
Tamar
On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones
mailto:simo...@microsoft.com>> wrote:
So I just say
make TEST
is that right?
Or is it
make THREADS=1
or what? Sorry to be dim
From: Phyx mailto:loneti...@gmail.com>>
Sent: 30 November 2018 08:05
To: Simon Peyton Jones mailto:simo...@microsoft.com>>
Cc: ghc-devs mailto:ghc-devs@haskell.org>>
Subject: Re: Windows test failures
Hi Simon,
Could you try rerunning those failing tests with make TEST? No threads? I have
been trying to clean up the testsuite and there should be only 3 failing tests,
two plugin tests with bad stdout and T10672_x64 which I am looking into.
I have however noticed that the testsuite has become increasingly unstable
under threads for some reason.
I also haven't run trunk yet since last week so they could be new..
But rerunning the fails with no threads should give a better idea.
Regards,
Tamar
On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs
mailto:ghc-devs@haskell.org>> wrote:
Ben, Phyx, and other CI folk
‘sh validate –fast’ still gives a lot of failures on Window. The output is
below. I would be so good to get this to zero!
(another minor thing is that it would be great to eliminate the long path at
the beginning – this is platform independent – I have to delete manually many
times each day.
Thanks
Simon
Unexpected passes:
/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
spaces/rts/T9405.run T9405 [unexpected] (normal)
Unexpected failures:
/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
spaces/driver/T14452.run T14452 [bad stdout] (normal)
/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
spaces/ghci/linking/ghcilink001.runghcilink001 [bad exit code]
(normal)
/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit code]
(ghci)
/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
spaces/ghci/scripts/ghci050.runghci050 [bad exit code]
(ghci)
/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
spaces/ghci/should_run/T14963a.run T14963a [bad exit code]
(ghci)
/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
spac
Re: Windows test failures
Hi,
I'm the author of test T14452. This is test #2 in the list of failing
tests of Simon. I looked into it and found, indeed, this test is broken
under Windows. Under Windows we get quotes around the -O3 ("-O3") but
not under Linux.
I'll reopen Trac ticket #14452 and prepare a patch with an improved
test!
Roland
Am Freitag, den 30.11.2018, 07:46 + schrieb Simon Peyton Jones via
ghc-devs:
> Ben, Phyx, and other CI folk
> ‘sh validate –fast’ still gives a lot of failures on Window. The
> output is below. I would be so good to get this to zero!
> (another minor thing is that it would be great to eliminate the long
> path at the beginning – this is platform independent – I have to
> delete manually many times each day.
> Thanks
> Simon
> Unexpected passes:
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/rts/T9405.run T9405 [unexpected] (normal)
>
> Unexpected failures:
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/driver/T14452.run T14452 [bad
> stdout] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci/linking/ghcilink001.run ghcilink001 [bad
> exit code] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad
> exit code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci/scripts/ghci050.run ghci050 [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci/should_run/T14963a.run T14963a [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci.debugger/scripts/print012.run print012 [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci.debugger/scripts/print016.run print016 [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci.debugger/scripts/break019.run break019 [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci.debugger/scripts/break028.run break028 [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad
> exit code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/plugins/plugin-recomp-change.run plugin-recomp-
> change [bad exit code] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/rts/T10672/T10672_x64.run T10672_x64 [bad
> exit code] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/th/TH_spliceGuard.run TH_spliceGuard
> [exit code non-0] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/th/TH_overlaps.run TH_overlaps [exit
> code non-0] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/th/T5886.run T5886 [exit code
> non-0] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/th/T10697_decided_3.run T10697_decided_3
> [exit code non-0] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/th/T11629.run T11629 [exit code
> non-0] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/libraries/base/tests/T4006.run T4006 [bad stdout]
> (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/libraries/base/tests/IO/environment001.run environment001
> [bad stdout] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/ghci/should_run/T15633b.run T15633b [bad exit
> code] (ghci)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/plugins/plugins07.run plugins07 [bad
> exit code] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/plugins/plugins09.run plugins09 [bad
> stdout] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/plugins/plugins10.run plugins10 [bad
> stdout] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/plugins/plugins11.run plugins11 [bad
> stdout] (normal)
> /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test
> spaces/p
Re: Windows test failures
Hi Simon, Could you try rerunning those failing tests with make TEST? No threads? I have been trying to clean up the testsuite and there should be only 3 failing tests, two plugin tests with bad stdout and T10672_x64 which I am looking into. I have however noticed that the testsuite has become increasingly unstable under threads for some reason. I also haven't run trunk yet since last week so they could be new.. But rerunning the fails with no threads should give a better idea. Regards, Tamar On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Ben, Phyx, and other CI folk > > ‘sh validate –fast’ still gives a lot of failures on Window. The output > is below. I would be so good to get this to zero! > > (another minor thing is that it would be great to eliminate the long path > at the beginning – this is platform independent – I have to delete manually > many times each day. > > Thanks > > Simon > > Unexpected passes: > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T9405.run T9405 [unexpected] (normal) > > > > Unexpected failures: > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/driver/T14452.run T14452 [bad stdout] > (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/linking/ghcilink001.runghcilink001 [bad exit > code] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit > code] (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/scripts/ghci050.runghci050 [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T14963a.run T14963a [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit > code] (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/indexed-types/should_fail/T7102a.runT7102a [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-change.runplugin-recomp-change > [bad exit code] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit > code] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_spliceGuard.run TH_spliceGuard [exit > code non-0] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_overlaps.run TH_overlaps [exit code > non-0] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T5886.runT5886 [exit code non-0] > (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T10697_decided_3.run T10697_decided_3 [exit > code non-0] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T11629.run T11629 [exit code non-0] > (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/T4006.run T4006 [bad stdout] > (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/environment001.run environment001 [bad > stdout] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T15633b.run T15633b [bad exit code] > (ghci) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins07.run plugins07 [bad exit > code] (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins09.run plugins09 [bad stdout] > (normal) > >/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins10.run plugins10 [bad stdout] > (normal) > >/c/Users/simon
Windows test failures
Ben, Phyx, and other CI folk 'sh validate -fast' still gives a lot of failures on Window. The output is below. I would be so good to get this to zero! (another minor thing is that it would be great to eliminate the long path at the beginning - this is platform independent - I have to delete manually many times each day. Thanks Simon Unexpected passes: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T9405.run T9405 [unexpected] (normal) Unexpected failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/driver/T14452.run T14452 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/linking/ghcilink001.runghcilink001 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/scripts/ghci050.runghci050 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T14963a.run T14963a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/indexed-types/should_fail/T7102a.runT7102a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-change.runplugin-recomp-change [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_spliceGuard.run TH_spliceGuard [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_overlaps.run TH_overlaps [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T5886.runT5886 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T10697_decided_3.run T10697_decided_3 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T11629.run T11629 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/T4006.run T4006 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T15633b.run T15633b [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins07.run plugins07 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins09.run plugins09 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins10.run plugins10 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins11.run plugins11 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/T10420.run T10420 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-flags.run
