GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:59:30Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4330Weird runtime Crash2019-07-07T18:59:30ZJoachim Breitnermail@joachim-breitner.deWeird runtime CrashI’m sure you like such summaries... but I could not do any better.
In the attached tarball is some code and a test.sh that can be used to show the bug. I tried to further reduce the size of the test case, but I’m in a position where any...I’m sure you like such summaries... but I could not do any better.
In the attached tarball is some code and a test.sh that can be used to show the bug. I tried to further reduce the size of the test case, but I’m in a position where any of numerous seemingly independent changes would cause the crash to not happen, including removing an unused binding of the form "blubb \<- return undefined", merging two Modules, removing unused imports or removing unused definitions.
Also disabling -O2 or -prof hides the patch.
I have attached my attempts to reduce the size of the testcase as a patch. Some code positions that can trigger or untrigger the bug are marked.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Weird runtime Crash","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I’m sure you like such summaries... but I could not do any better.\r\n\r\nIn the attached tarball is some code and a test.sh that can be used to show the bug. I tried to further reduce the size of the test case, but I’m in a position where any of numerous seemingly independent changes would cause the crash to not happen, including removing an unused binding of the form \"blubb <- return undefined\", merging two Modules, removing unused imports or removing unused definitions.\r\n\r\nAlso disabling -O2 or -prof hides the patch.\r\n\r\nI have attached my attempts to reduce the size of the testcase as a patch. Some code positions that can trigger or untrigger the bug are marked.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4274Runtime should not set SIGPIPE to ignored for subprocesses2019-07-07T18:59:45Zphunge0Runtime should not set SIGPIPE to ignored for subprocessesThe GHC runtime ignores SIGPIPE by setting the signal
to SIG_IGN. This means that any subprocesses (created via
System.Process or otherwise) inwill also have their
SIGPIPE handler set to SIG_IGN; I think this might be
a bug. The Python r...The GHC runtime ignores SIGPIPE by setting the signal
to SIG_IGN. This means that any subprocesses (created via
System.Process or otherwise) inwill also have their
SIGPIPE handler set to SIG_IGN; I think this might be
a bug. The Python runtime does the same thing,
there's a good explanation of the drawbacks in:
http://bugs.python.org/issue1652
IMHO the simplest fix is the patch below: simply
avoid SIG_IGN, instead install a handler which does nothing.
This way, an exec() restores the handler to SIG_DFL. I've
included a testcase too.
Discussion link: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-August/019091.html. Summarizing: Donn Cave expressed concern that installing a signal handler for SIGPIPE might not be transparent to the rest of the program, but since the runtime already uses signal handlers for SIGVTALRM, it shouldn't make matters any worse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Runtime should not set SIGPIPE to ignored for subprocesses","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC runtime ignores SIGPIPE by setting the signal\r\nto SIG_IGN. This means that any subprocesses (created via\r\nSystem.Process or otherwise) inwill also have their\r\nSIGPIPE handler set to SIG_IGN; I think this might be\r\na bug. The Python runtime does the same thing,\r\nthere's a good explanation of the drawbacks in:\r\nhttp://bugs.python.org/issue1652\r\n\r\nIMHO the simplest fix is the patch below: simply\r\navoid SIG_IGN, instead install a handler which does nothing.\r\nThis way, an exec() restores the handler to SIG_DFL. I've\r\nincluded a testcase too.\r\n\r\nDiscussion link: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-August/019091.html. Summarizing: Donn Cave expressed concern that installing a signal handler for SIGPIPE might not be transparent to the rest of the program, but since the runtime already uses signal handlers for SIGVTALRM, it shouldn't make matters any worse.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1Simon MarlowSimon Marlow