GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-02-25T01:15:51Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16066internal error: PAP object entered!2020-02-25T01:15:51Zdnspiesinternal error: PAP object entered!While trying to debug why my test didn't seem to be running, I got an internal error (below).
After a clean and rebuild it happened again so it's not a flake. Unfortunately I don't know what's causing it so I can't produce an MWE, but I...While trying to debug why my test didn't seem to be running, I got an internal error (below).
After a clean and rebuild it happened again so it's not a flake. Unfortunately I don't know what's causing it so I can't produce an MWE, but I can link to the project and commit on GitHub:
https://github.com/dspies-leapyear/persistwrap/tree/885a079923cb3eefb24db344f5e2fddee9fab425
Just run the test with:
```
stack test persistwrap:persistwrap-test
```
```
Progress 9/10: persistwrap-0.1.0.0test/Driver.hs
test_widget_schemas: persistwrap-test: internal error: PAP object entered!
(GHC version 8.4.4 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
persistwrap-test: SignalException 6
persistwrap-0.1.0.0: Test suite persistwrap-test failed
Completed 10 action(s).
Test suite failure for package persistwrap-0.1.0.0
persistwrap-test: exited with: ExitFailure (-6)
Logs printed to console
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| 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":"internal error: PAP object entered!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While trying to debug why my test didn't seem to be running, I got an internal error (below).\r\n\r\nAfter a clean and rebuild it happened again so it's not a flake. Unfortunately I don't know what's causing it so I can't produce an MWE, but I can link to the project and commit on GitHub:\r\n\r\nhttps://github.com/dspies-leapyear/persistwrap/tree/885a079923cb3eefb24db344f5e2fddee9fab425\r\n\r\nJust run the test with:\r\n\r\n{{{\r\nstack test persistwrap:persistwrap-test\r\n}}}\r\n\r\n{{{\r\nProgress 9/10: persistwrap-0.1.0.0test/Driver.hs\r\n test_widget_schemas: persistwrap-test: internal error: PAP object entered!\r\n (GHC version 8.4.4 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\npersistwrap-test: SignalException 6\r\n\r\npersistwrap-0.1.0.0: Test suite persistwrap-test failed\r\nCompleted 10 action(s).\r\nTest suite failure for package persistwrap-0.1.0.0\r\n persistwrap-test: exited with: ExitFailure (-6)\r\nLogs printed to console\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16846RTS STM Segmentation fault on Linux/MacOS2020-05-29T05:40:02ZPhilip KamenarskyRTS STM Segmentation fault on Linux/MacOS# Summary
[stm-bug.tar.gz](/uploads/f391344d67b7de42182ba9cbe672b968/stm-bug.tar.gz)
Compiling and running the attached project segfaults on both Linux and MacOs on GHC 8.0 through 8.6. I tried minimising the code as much as possible, ...# Summary
[stm-bug.tar.gz](/uploads/f391344d67b7de42182ba9cbe672b968/stm-bug.tar.gz)
Compiling and running the attached project segfaults on both Linux and MacOs on GHC 8.0 through 8.6. I tried minimising the code as much as possible, but I've reached a point where even inlining terms masks the segfault. Also, not using STM `retry` masks the segfault. Also, the code has to be spread across two modules, the segfault doesn't occur if everything is in e.g. Main.hs.
Sometimes, the RTS manages to shut down before a hard crash, i.e.:
```
stm-bug-0.1.0.0: unregistering (local file changes: src/Lib.hs)
stm-bug-0.1.0.0: build (lib + exe)
Preprocessing library for stm-bug-0.1.0.0..
Building library for stm-bug-0.1.0.0..
[2 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/Lib.o )
Preprocessing executable 'stm-bug-exe' for stm-bug-0.1.0.0..
Building executable 'stm-bug-exe' for stm-bug-0.1.0.0..
[1 of 2] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/stm-bug-exe/stm-bug-exe-tmp/Main.o ) [Lib changed]
Linking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/stm-bug-exe/stm-bug-exe ...
stm-bug-0.1.0.0: copy/register
Installing library in /home/phil/Projects/stm-bug/.stack-work/install/x86_64-linux/lts-13.26/8.6.5/lib/x86_64-linux-ghc-8.6.5/stm-bug-0.1.0.0-FnTyJxtuwWMDN9Vt5S3LQp
Installing executable stm-bug-exe in /home/phil/Projects/stm-bug/.stack-work/install/x86_64-linux/lts-13.26/8.6.5/bin
Registering library for stm-bug-0.1.0.0..
stm-bug-exe: internal error: evacuate: strange closure type 9435472
(GHC version 8.6.5 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
Other error messages while isolating the test case where included references to `strange closure type 4325519`, `stg_ap_p_ret`, and `stg_END_STM_WATCH_QUEUE_closure`.
# Steps to reproduce
```
stack build && stack exec stm-bug-exe
```
# Expected behavior
Not segfault.
# Environment
* GHC version used: 8.0.* - 8.6.* (didn't test with 7.*)
* gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10), Apple LLVM version 10.0.0 (clang-1000.11.45.5)
# Optional:
* Operating System: Linux, MacOS, maybe Windows
* System Architecture:8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16182Retainer Profiling is broken2019-07-07T18:01:04ZEric CrockettRetainer Profiling is brokenI had a large program which I was trying to profile, and I noticed that the program always ran into a segfault when running with `+RTS -hr`. I was able to able to reliably get segfaults in both the `warp-tls` and `http-client-tls` packag...I had a large program which I was trying to profile, and I noticed that the program always ran into a segfault when running with `+RTS -hr`. I was able to able to reliably get segfaults in both the `warp-tls` and `http-client-tls` packages, as well as a third large and independent package with essentially no overlapping dependencies. This led me to believe that the bug is in the retainer profiler itself, and is not (much) dependent on the code being profiled. To that point, I was able to reproduce the bug with the `bytestring` test suites.
I've modified bytestring (attached) enough to make it compile with GHC 8.6.3. To reproduce the segfault, run
```
$ stack build --profile
$ stack exec prop-compiled -- +RTS -hr
```
I have confirmed the problem on Linux (Ubuntu 18.04), where prop-compiled quickly segfaults, and on Windows 10, where the program just hangs. \[I observed the same behavior in all the other programs I tested: Linux segfaulted, and Windows just hung.\]
Changes to bytestring:
1. Renamed the package to bytestring2 to avoid circular packages.
1. Removed a duplicate instance in tests/QuickCheckUtils.hs
1. Changed all test-suites to executables in the cabal file so that they could be compiled with profiling.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16117Random segfaults at runtime on macOS Mojave caused by GHC linker misaligning ...2019-10-28T03:19:17ZgwynneRandom segfaults at runtime on macOS Mojave caused by GHC linker misaligning sectionsGHC-built binaries sometimes crash at runtime on Mojave. The crash is caused by the incorrect practice of loading static archives directly into memory. The `align` field of the various sections in the `__TEXT` segment is not respected; i...GHC-built binaries sometimes crash at runtime on Mojave. The crash is caused by the incorrect practice of loading static archives directly into memory. The `align` field of the various sections in the `__TEXT` segment is not respected; instead the entire file is mapped directly in using `mmap()`, which results in sections often loading at addresses which are only 8-byte aligned. The files on disk are not properly aligned, since `ld` was never given the opportunity to correctly arrange them. In turn, this causes any SSE instructions which load from memory (as found in, especially, crypto algorithms implemented in C) to raise `#GP` faults - SSE memory loads require 16-byte alignment. It's essentially blind luck that this has been working for any length of time in the past.
This technique of loading static archives directly into memory at runtime is problematic at best; this crash is far from the only issue. With no involvement by `ld` and `dyld`, no symbols or debug information were available. There was absolutely no evidence anywhere in the crash logs to even make a start at tracking down the issue; only the presence of a consistent repro case and a lot of examining memory regions by hand made finding the root cause possible. `MH_OBJECT` files are not intended to be treated as final executable code. And to add insult to injury, the technique is fundamentally incompatible with code signing. Re-implementing parts of `dyld` by hand like this is not a replacement for macOS not supporting static linking.
In the absence of switching to a supported behavior (e.g. dynamic loading), an appropriate fix consists of:
1. Disable the `mmap()` codepath in the Mach-O loader. It prevents correct alignment handling and does not provide a significant performance benefit.
1. Teach the loader to handle alignment on a section-by-section (*not* segment!) basis and to correctly apply the appropriate relocations. The existing "align the entire file" codepath is not sufficient.
1. Remove the conceit that there will be only one segment to load.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Random segfaults at runtime on macOS Mojave caused by GHC linker misaligning sections","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC-built binaries sometimes crash at runtime on Mojave. The crash is caused by the incorrect practice of loading static archives directly into memory. The `align` field of the various sections in the `__TEXT` segment is not respected; instead the entire file is mapped directly in using `mmap()`, which results in sections often loading at addresses which are only 8-byte aligned. The files on disk are not properly aligned, since `ld` was never given the opportunity to correctly arrange them. In turn, this causes any SSE instructions which load from memory (as found in, especially, crypto algorithms implemented in C) to raise `#GP` faults - SSE memory loads require 16-byte alignment. It's essentially blind luck that this has been working for any length of time in the past.\r\n\r\nThis technique of loading static archives directly into memory at runtime is problematic at best; this crash is far from the only issue. With no involvement by `ld` and `dyld`, no symbols or debug information were available. There was absolutely no evidence anywhere in the crash logs to even make a start at tracking down the issue; only the presence of a consistent repro case and a lot of examining memory regions by hand made finding the root cause possible. `MH_OBJECT` files are not intended to be treated as final executable code. And to add insult to injury, the technique is fundamentally incompatible with code signing. Re-implementing parts of `dyld` by hand like this is not a replacement for macOS not supporting static linking.\r\n\r\nIn the absence of switching to a supported behavior (e.g. dynamic loading), an appropriate fix consists of:\r\n1. Disable the `mmap()` codepath in the Mach-O loader. It prevents correct alignment handling and does not provide a significant performance benefit.\r\n2. Teach the loader to handle alignment on a section-by-section (''not'' segment!) basis and to correctly apply the appropriate relocations. The existing \"align the entire file\" codepath is not sufficient.\r\n3. Remove the conceit that there will be only one segment to load.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15292ghc_ticker loops if permission denied on timerfd2019-07-07T18:13:24Zjon.fairbairn@cl.cam.ac.ukghc_ticker loops if permission denied on timerfdUsing stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd.
This is caused by selinux preventing read on the timer. Changing the selunix p...Using stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd.
This is caused by selinux preventing read on the timer. Changing the selunix permissions solves the problems, but ghc-ticker ought to check whether the read succeeded and not try again if it fails.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| 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":"ghc_ticker loops if permission denied on timerfd","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd.\r\nThis is caused by selinux preventing read on the timer. Changing the selunix permissions solves the problems, but ghc-ticker ought to check whether the read succeeded and not try again if it fails.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16784PLT is mapped in too far from code2019-06-12T12:48:01ZBen GamariPLT is mapped in too far from codeThe procedure linkage table (PLT) is mapped too far from code on AArch64. This is the cause of #16776.
It should be using similar logic to that which is used on x86-64, where we take particular care to feed `mmap` an unmapped hint addre...The procedure linkage table (PLT) is mapped too far from code on AArch64. This is the cause of #16776.
It should be using similar logic to that which is used on x86-64, where we take particular care to feed `mmap` an unmapped hint address in the lower 2GB of address space.8.8.1Ben GamariBen Gamari