Crashes observed in GHC dynamic linker on macOS when invoking Template Haskell splices via GHC as a statically linked library

Summary

When working with the haskell-language-server executable, I encountered a crash in the GHC dynamic linker that the standard haskell-language-server distribution (as installed via ghcup) embeds statically. Telling ghcide to compile a Template Haskell splice provided by the optics library produces a SIGSEGV crash. A DWARF backtrace:

* thread #55, stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
  * frame #0: 0x0000000105bcda8b haskell-language-server`ocResolve_MachO [inlined] relocateSection(oc=<unavailable>, curSection=0) at MachO.c:680:40 [opt]
    frame #1: 0x0000000105bcda6d haskell-language-server`ocResolve_MachO(oc=0x000000010be4adb0) at MachO.c:1529 [opt]
    frame #2: 0x0000000105b9d4d4 haskell-language-server`ocTryLoad(oc=0x000000010be4adb0) at Linker.c:1735:9 [opt]
    frame #3: 0x0000000105b9d315 haskell-language-server`lookupSymbol_ at Linker.c:898:17 [opt]
    frame #4: 0x0000000105b9d2f7 haskell-language-server`lookupSymbol_(lbl="_ptcszmcrzm0zi3zi0zi1zm0e46846a_OpticsziInternalziOpticziTypes_zdtcAzuLens_closure") at Linker.c:878 [opt]
    frame #5: 0x0000000105bcddd5 haskell-language-server`ocResolve_MachO at MachO.c:848:24 [opt]
    frame #6: 0x0000000105bcda6d haskell-language-server`ocResolve_MachO(oc=0x000000010be61080) at MachO.c:1529 [opt]
    frame #7: 0x0000000105b9d4d4 haskell-language-server`ocTryLoad(oc=0x000000010be61080) at Linker.c:1735:9 [opt]
    frame #8: 0x0000000105b9d315 haskell-language-server`lookupSymbol_ at Linker.c:898:17 [opt]
    frame #9: 0x0000000105b9d2f7 haskell-language-server`lookupSymbol_(lbl="_ptcszmthzm0zi3zi0zi2zm4f2a2ac9_LanguageziHaskellziTHziOpticsziInternal_zdfSubstTypeTypezuzdcsubstType_closure") at Linker.c:878 [opt]
    frame #10: 0x0000000105bcddd5 haskell-language-server`ocResolve_MachO at MachO.c:848:24 [opt]
    frame #11: 0x0000000105bcda6d haskell-language-server`ocResolve_MachO(oc=0x000000010be5c210) at MachO.c:1529 [opt]
    frame #12: 0x0000000105b9d4d4 haskell-language-server`ocTryLoad(oc=0x000000010be5c210) at Linker.c:1735:9 [opt]
    frame #13: 0x0000000105b9d315 haskell-language-server`lookupSymbol_ at Linker.c:898:17 [opt]
    frame #14: 0x0000000105b9d2f7 haskell-language-server`lookupSymbol_(lbl="_ptcszmthzm0zi3zi0zi2zm4f2a2ac9_OpticsziTHziInternalziUtils_zdwquantifyTypezq_info") at Linker.c:878 [opt]
    frame #15: 0x0000000105bcddd5 haskell-language-server`ocResolve_MachO at MachO.c:848:24 [opt]
    frame #16: 0x0000000105bcda6d haskell-language-server`ocResolve_MachO(oc=0x000000010be5d400) at MachO.c:1529 [opt]
    frame #17: 0x0000000105b9d4d4 haskell-language-server`ocTryLoad(oc=0x000000010be5d400) at Linker.c:1735:9 [opt]
    frame #18: 0x0000000105b9d315 haskell-language-server`lookupSymbol_ at Linker.c:898:17 [opt]
    frame #19: 0x0000000105b9d2f7 haskell-language-server`lookupSymbol_(lbl="_ptcszmthzm0zi3zi0zi2zm4f2a2ac9_OpticsziTHziInternalziProduct_LensRules_con_info") at Linker.c:878 [opt]
    frame #20: 0x0000000105bcddd5 haskell-language-server`ocResolve_MachO at MachO.c:848:24 [opt]
    frame #21: 0x0000000105bcda6d haskell-language-server`ocResolve_MachO(oc=0x000000010be5a230) at MachO.c:1529 [opt]
    frame #22: 0x0000000105b9d4d4 haskell-language-server`ocTryLoad(oc=0x000000010be5a230) at Linker.c:1735:9 [opt]
    frame #23: 0x0000000105b9d315 haskell-language-server`lookupSymbol_ at Linker.c:898:17 [opt]
    frame #24: 0x0000000105b9d2f7 haskell-language-server`lookupSymbol_(lbl="_ptcszmthzm0zi3zi0zi2zm4f2a2ac9_OpticsziTH_makeFieldLabels_closure") at Linker.c:878 [opt]
    frame #25: 0x0000000105b9d560 haskell-language-server`lookupSymbol(lbl="_ptcszmthzm0zi3zi0zi2zm4f2a2ac9_OpticsziTH_makeFieldLabels_closure") at Linker.c:916:21 [opt]
    frame #26: 0x00000001055d6169 haskell-language-server`Lc3pa_info + 49

This appears to manifest only on macOS, and the backtrace suggests that it’s crashing while trying to resolve a Mach-O symbol.

Though I was able to work around this bug by compiling haskell-language-server with the -dynamic flag, @pepeiborra asked me to submit this upstream as a GHC bug, hence this report. Please note that the original haskell-language-server bug report can be found here.

Write a brief description of the issue.

Steps to reproduce

I don’t have a GHC-specific test case for this functionality yet; I apologize for the inconvenience. @pepeiborra suggested compiling a GHC with DYNAMIC_GHC_PROGRAMS set to NO, which I am trying. As it stands, the fastest way to reproduce is this:

• compile or download haskell-language-server
• git clone https://github.com/patrickt/possession.git; cd possession; haskell-language-server-wrapper
• Observe as invoking the makeFieldLabels splice crashes the language server.
• Recompile haskell-language-server with the -dynamic flag
• Observe that no crash occurs

Expected behavior

No crash.

Environment

• GHC version used: 8.10.2

Optional:

• Operating System: macOS Catalina v10.15.7
• System Architecture: x86_64