#10686: Process stops responding to sigINT -------------------------------------+------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Every now and then the leksah-server process has required a kill -9 it to get rid of it. Now Leksah is using the threaded RTS it seems to be happening in Leksah too. It is worse in Leksah because child processes inherit the behaviour and do not terminate when sent Leksah sends them sigINT (which Leksah does very frequently). Once the problem arrises it continues until the Leksah is restarted. Both leksah-server and Leksah start child processes using the process package. I think process package and the GHC GC both call blockUserSignals and it only has one place to store savedSignals. My guess is that two calls go into blockUserSignals from different threads before unblockUserSignals is called on either. The result is that when unblockUserSignals is called it does nothing (because savedSignals was overwritten). Perhaps savedSignals could use some kind of thread local storage? Also docs seem to indicate sigprocmask should not be used at all in multithreaded processes. Perhaps the GHC RTS should use pthread_sigprocmask instead? If the calling process delegates Ctrl+C the problem might be largely hidden. The sigINT signal is enabled again in the child fork and the parent will get an exception if the child is terminated with a sigINT. However I believe the parent is still left in a state where it will no longer respond to sigINT if the child process terminates normally (assuming two calls in a row were made to blockUserSignals at some point). The work around for now in Leksah is to reenable sigINT before each createProcess call. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10686 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler