> On FreeBSD using ghc 4.04, long running commands executed with
> System.system are being interrupted by virtual alarms leading to
> errors such as:
>
> o Fail: interrupted
> Action: system
> Reason: system command interrupted rm -f xxx yyy
>
> o Virtual timer expired
>
> o gcc: Internal compiler error: program cpp got fatal signal 26
>
> (Depending on which command was interrupted.)
>
>
> After looking at ghc 4.02's libraries for a while (it's all I had
> around), it looks as though ghc-4.02/ghc/lib/std/cbits/system.c should
> mask the SIGVTALRM signal after executing fork and before executing
> exec*. (Obviously it should also mask any other signals not set by
> the users code.)
I don't get it - execve() and friends are supposed to reset all the signal
handlers back to the default state, aren't they? And I can't seem to
construct an example to demonstrate the problem.
> [Incidentally, I'm not sure why this SIGVTALRM is enabled though since
> the online documentation for -C says that context switches happen on
> heap checks not on timeouts.]
We use SIGVTALRM now for supporting threadDelay.
> ps I'm guessing that problem has been in the code ever since it was
> written - wonder why it's never hit anyone before?
I'm confused too :)
Simon
