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 <[email protected]> > 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/ _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
