GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-06-26T17:46:37Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16842References to unloaded CAFs due to stale static flag field2019-06-26T17:46:37ZBen GamariReferences to unloaded CAFs due to stale static flag fieldThis issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (...This issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (which set the static link field to 3) and thus were ignored by GC. Because of that, during the next GC, checkUnload determined that these ObjectCode struct can be freed despite the references into those ObjectCodes still existing. Next GC cycle would trigger crash while GC is trying to evacuate the mentioned CAFs.8.8.1Ben GamariBen Gamarihttps://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 Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16779elf_got remaps GOT region as read-only too early2019-06-12T12:45:24ZBen Gamarielf_got remaps GOT region as read-only too early67c422ca0e7b94e021430e3dfc9b19f3de21ed16 taught the linker to remap regions as read-only after linking where appropriate. However, it is a bit overzealous in the case of GOTs (as I originally noted in https://gitlab.haskell.org/ghc/ghc/i...67c422ca0e7b94e021430e3dfc9b19f3de21ed16 taught the linker to remap regions as read-only after linking where appropriate. However, it is a bit overzealous in the case of GOTs (as I originally noted in https://gitlab.haskell.org/ghc/ghc/issues/16776#note_204499). Specifically, `elf_got.c:makeGot` `mprotect`s the GOT region after partially filling it. However, `elf_got.c:fillGot` also needs to write to the GOT region and is called *after* the `mprotect`. Consequently we crash.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/13786GHCi linker is dependent upon object file order2020-02-17T11:34:32ZppelletiGHCi linker is dependent upon object file orderUsing [this package](https://github.com/ppelleti/hs-mercury-api), I tried doing "stack repl" with GHC 8.0.2:
```
whiteandnerdy:hs-mercury-api ppelleti$ stack repl
The following GHC options are incompatible with GHCi and have not been pa...Using [this package](https://github.com/ppelleti/hs-mercury-api), I tried doing "stack repl" with GHC 8.0.2:
```
whiteandnerdy:hs-mercury-api ppelleti$ stack repl
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
* * * * * * * *
The main module to load is ambiguous. Candidates are:
1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-firmware.hs
2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs
3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs
4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs
5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs
6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs
You can specify which one to pick by:
* Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr-firmware
* Specifying what the main is e.g. stack ghci --main-is mercury-api:exe:tmr-firmware
* Choosing from the candidate above [1..6]
* * * * * * * *
Specify main module to use (press enter to load none): 4
Loading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs
Configuring GHCi with the following packages: mercury-api
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading
Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib
Expected in: flat namespace
in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This bug appears to have been around a while, because it also happens with GHC 7.8.3:
```
whiteandnerdy:hs-mercury-api ppelleti$ cabal repl
Preprocessing library mercury-api-0.1.0.0...
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package text-1.2.2.1 ... linking ... done.
Loading package hashable-1.2.6.0 ... linking ... done.
Loading package unordered-containers-0.2.8.0 ... linking ... done.
Loading package clock-0.7.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package unix-2.7.0.1 ... linking ... done.
Loading package ansi-terminal-0.6.2.3 ... linking ... done.
Loading object (static) dist/build/cbits/api/tmr_strerror.o ... done
Loading object (static) dist/build/cbits/api/tmr_param.o ... done
Loading object (static) dist/build/cbits/api/hex_bytes.o ... done
Loading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit
Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib
Expected in: flat namespace
in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I'm using Mac OS X 10.9.5:
```
whiteandnerdy:hs-mercury-api ppelleti$ uname -a
Darwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic on Mac OS X with \"cabal repl\" / \"stack repl\" on GHC 8.0.2 and 7.8.3","status":"New","operating_system":"MacOS X","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Using [https://github.com/ppelleti/hs-mercury-api this package], I tried doing \"stack repl\" with GHC 8.0.2:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ stack repl\r\nThe following GHC options are incompatible with GHCi and have not been passed to it: -threaded\r\n\r\n* * * * * * * *\r\nThe main module to load is ambiguous. Candidates are: \r\n1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-firmware.hs\r\n2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs\r\n3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs\r\n4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs\r\n5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs\r\n6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs\r\nYou can specify which one to pick by: \r\n * Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr-firmware\r\n * Specifying what the main is e.g. stack ghci --main-is mercury-api:exe:tmr-firmware\r\n * Choosing from the candidate above [1..6]\r\n* * * * * * * *\r\n\r\nSpecify main module to use (press enter to load none): 4\r\nLoading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs\r\n\r\nConfiguring GHCi with the following packages: mercury-api\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-apple-darwin):\r\n\tLoading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading\r\n Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib\r\n Expected in: flat namespace\r\n in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThis bug appears to have been around a while, because it also happens with GHC 7.8.3:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ cabal repl\r\nPreprocessing library mercury-api-0.1.0.0...\r\nGHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package bytestring-0.10.4.0 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\nLoading package binary-0.7.1.0 ... linking ... done.\r\nLoading package text-1.2.2.1 ... linking ... done.\r\nLoading package hashable-1.2.6.0 ... linking ... done.\r\nLoading package unordered-containers-0.2.8.0 ... linking ... done.\r\nLoading package clock-0.7.2 ... linking ... done.\r\nLoading package old-locale-1.0.0.6 ... linking ... done.\r\nLoading package time-1.4.2 ... linking ... done.\r\nLoading package unix-2.7.0.1 ... linking ... done.\r\nLoading package ansi-terminal-0.6.2.3 ... linking ... done.\r\nLoading object (static) dist/build/cbits/api/tmr_strerror.o ... done\r\nLoading object (static) dist/build/cbits/api/tmr_param.o ... done\r\nLoading object (static) dist/build/cbits/api/hex_bytes.o ... done\r\nLoading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-apple-darwin):\r\n\tLoading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit\r\n Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib\r\n Expected in: flat namespace\r\n in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI'm using Mac OS X 10.9.5:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ uname -a\r\nDarwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamari