topHandler03 failing

[Duncan Coutts]

On Fri, 2013-11-15 at 11:21 +0100, Joachim Breitner wrote:
> Hi,
> 
> I don’t trust the travis setup enough to automatically relay failures,
> so I do it manually. Since these patches:
> 
> Changes to ghc:
> Changes to base:
> commit dd00004
> Author: Duncan Coutts <duncan at well-typed.com>
> Date:   Thu Nov 14 15:16:30 2013 +0000
> 
>     Add tests for the top level exception handler

>     So we test that:

>     3. an unhandled ExitFailure (-sig) makes us kill ourselves with sig

[..snip..]

> I get this failure on travis:
> 
> =====> topHandler03(normal) 3622 of 3821 [0, 0, 0] 
> Actual stderr output differs from expected:
> --- /dev/null	2013-11-14 17:46:34.724312327 +0000
> +++ ../../libraries/base/tests/topHandler03.run.stderr	2013-11-14 18:24:52.367542630 +0000
> @@ -0,0 +1 @@
> +Terminated

> Does anyone feel responsible?

Yep, that'd be me.

Turns out it's an annoying difference in shell behaviour between systems
(or maybe even configurations). When a process exits with a signal, some
shells print out a line indicating what the signal was, e.g.
"Terminated" for SIGTERM, oh "Hangup" for SIGHUP.

$ sh -c 'kill -TERM $$'
Terminated

For some reason on my system I didn't get any message so I didn't
notice. Anyway, the solution was to annotate the test runner so it
ignores stdout for that test.

I have no idea why our python test framework is running the Haskell
progs via a shell, rather than directly. It also means that the exit
code handling is rather messed up (see the python test driver code for
all the e << 8, e >> 8 bit twiddling madness); instead of cleanly
getting the exit signal, we get an encoding using 128 + sig.

-- 
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/