signal handlers are invoked multiple times when the threaded rts is used

When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this:

import Control.Concurrent
import System.Posix.Signals

main :: IO ()
main = do
    _ <- flip (installHandler sig) Nothing $ Catch $
        putStrLn $ "Received signal " ++ show sig
    raiseSignal sig
    threadDelay 100000
  where
    sig = sigUSR2

If you compile this with the -threaded flag and then run it with say +RTS -N4 then it produces the following output:

Received signal 12
Received signal 12
Received signal 12
Received signal 12
Received signal 12

In general the signal handler is invoked n_capabilities+1 times. This also happens with all other signals.

This regression was introduced by f9f89b78 (which was later [changeset:4748f593 reverted] but then [changeset:7e658bc1 re-added]), a commit addressing #9423 (closed).

The cause of the problem is [source:/rts/posix/Signals.c@f44bbc83#L256 this] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens [source:/rts/posix/Signals.c@f44bbc83#L183 here])?

Removing the loop seems to solve the issue, but I don't know if it makes #9423 (closed) reappear. I cannot test this on a Mac OS X right now.

Trac metadata

Trac field	Value
Version	7.10.1-rc1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	AndreasVoellmy, simonmar
Operating system
Architecture

changed weight to 5

added RTS Tbug Trac import labels

changed milestone to %7.10.1

changed weight to 10

Yikes. Austin: this looks like a release blocker.

Trac metadata

Trac field	Value
Priority	normal → highest

I'm still getting up to speed, but it looks like that offending loop in generic_handler should just be removed. We have to signal to all the control pipes in ioManagerDie() (to solve the issue that led to that commit), but not in generic_handler (it seems). I'll look into it a bit more to check my understand and run some tests.

assigned to @trac-AndreasVoellmy and unassigned @simonmar

Trac metadata

Trac field	Value
Differential revisions	→ D641

In the threaded RTS, a signal is delivered from the RTS to Haskell user code by writing to file that one of the IO managers watches (via an instance of GHC.Event.Control.Control). When the IO manager receives the signal, it calls GHC.Conc.Signal.runHandlers to invoke Haskell signal handler. In the move from a single IO manager to one IO manager per capability, the behavior was (wrongly) extended so that a signal is delivered to every event manager (see Trac #9423 (closed)), each of which invoke Haskell signal handlers, leading to multiple invocations of Haskell signal handlers for a single signal. This change fixes this problem by having the RTS (in generic_handler()) notify only the Control instance used by the TimerManager, rather than all the per-capability IO managers.

This has no impact on #9423 (closed); i.e. the fix here does not re-introduce the issue identified in #9423 (closed).

mentioned in commit 92c93544

added 1 deleted label

closed

Boom, headshot. Merged to ghc-7.10 via ddd95c0b.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

removed 1 deleted label

mentioned in commit bb0e462b

added incorrect runtime result label

added Phighest label