Re: topHandler03 failing

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 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/