topHandler03 failing

[Joachim Breitner]

Hi,

I don’t trust the travis setup enough to automatically relay failures,
so I do it manually. Since these patches:

Changes to ghc:
commit 12cdd6d
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 16:02:03 2013 +0000

    Don translate UserInterrupt into ExitFailure 1, let it propagate

    It is important that if a program recieved ^C from the user, and the
    program terminates as a result, that it exit with SIGINT so that the
    parent process knows that was the case. For example cabal calling ghc
    will then be able to tell the difference between it failing and the user
    interrupting with ^C and report (or not) appropriately.

    So we should just let the UserInterrupt exception propagate to the top
    level error handler which will do the right thing.

    See http://www.cons.org/cracauer/sigint.html

commit a987b80
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 15:54:13 2013 +0000

    Improve the shutdownHaskellAndSignal and add fast exit

    This is the RTS part of a patch to base's topHandler to handle exiting
    by a signal.

    The intended behaviour is that on Unix, throwing ExitFailure (-sig)
    results in the process terminating with that signal. Previously
    shutdownHaskellAndSignal was only used for exiting with SIGINT due to
    the UserInterrupt exception.

    Improve shutdownHaskellAndSignal to do the signal part more carefully.
    In particular, it (should) now reliably terminates the process one way
    or another. Previusly if the signal was blocked, ignored or handled then
    shutdownHaskellAndSignal would actually return!

    Also, the topHandler code has two paths a careful shutdown and a "fast
    exit" where it does not give finalisers a chance to run. We want to
    support that mode also when we want to exit by signal. So rather than
    the base code directly calling stg_exit as it did before, we have a
    fastExit bool paramater for both shutdownHaskellAnd{Exit,Signal}.

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

    The top level exception handler is wrapped around main, and FFI exports.
    It handles exceptions that are not otherwise caught in user code. For
    most exception is just prints them, but handles a few specially,
    including ExitCode and UserInterrupt.

    On Unix it installs a signal handler for SIGINT to translate it into a
    UserInterrupt async exception.

    So we test that:

    1. receiving SIGINT does trigger a UserInterrupt async exception
    2. an unhandled UserInterrupt makes us kill ourselves with SIGINT
    3. an unhandled ExitFailure (-sig) makes us kill ourselves with sig

commit 6b22a6e
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 15:15:31 2013 +0000

    Handle ExitFailure (-sig) by killing process with signal

    On Unix we now use negative exit codes in ExitFailure to indicate that a
    process exited due to a signal. This patch implements the case for when
    a ExitFailure exception propagates out of the top of main (and is
    handled by the topHandler).

    For a negative ExitFailure code, we try to kill the process using that
    signal (the details of that are handled by shutdownHaskellAndSignal from
    the RTS). For an exit code outside the valid ranges, we use 0xff.

Changes to process:
commit 3ebbe13
Author: Duncan Coutts <duncan at well-typed.com>
Date:   Thu Nov 14 13:59:57 2013 +0000

    Change the unix ExitCode encoding again! Now simply -signum

    So rather than a bitfield encoding, covering normal exit codes, signals
    and core dumps, we now simply use negative numbers for signal exit
    codes. We thus do not report core dumps by this mechanism.

    This encoding is a lot simpler to explain and use. It also happens to be
    the same encoding as Python's subprocess package uses.

    Anyone who cares about core dumps can still use the unix package.

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
*** unexpected failure for topHandler03(normal)

(Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/13982142/log.txt)

Does anyone feel responsible?

Greetings,
Joachim



-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131115/cb18d907/attachment.sig>