duncan at well-typed.com
Fri Nov 15 14:06:32 UTC 2013
On Fri, 2013-11-15 at 11:21 +0100, Joachim Breitner wrote:
> 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
> 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 @@
> 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 $$'
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/
More information about the ghc-devs