Windows test failures

[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 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 <rsx at bluewin.ch> 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 +0000 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181204/cc93ec53/attachment.html>