#9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #8935 Comment: More `environ` nightmares, with the added twist of the GHCi linker. The problem arises here in `PrelIOUtils.o`: {{{ 00000000000002b0 <__hscore_environ>: 2b0: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 2b7 <__hscore_environ+0x7> 2b3: R_X86_64_PC32 environ-0x4 2b7: c3 retq }}} `-Dl` has the following to say about this: [edited slightly for readability] {{{ Rel entry 2 is raw( 0x2b3 0x3a00000002 0xfffffffffffffffc) lookupSymbol: looking up environ initLinker: start initLinker: idempotent return lookupSymbol: symbol not found `environ' resolves to 0x7ffff7039fd8 Reloc: P = 0x44f0e2f3 S = 0x7ffff7039fd8 A = 0xfffffffffffffffc }}} Now `environ` is too far away to use a PC-relative 32-bit reference, so the GHCi linker makes a jump island, but that's nonsense since `environ` isn't a function but rather a pointer to an array of C strings. But, also `0x7ffff7039fd8` isn't the ''right'' `environ` according to gdb: there is NULL there. What gdb thinks is `environ` (and my environment does actually appear there) is `0x7ffff7ffe140`... which is also too far away from the relocation site. I wonder how this all worked when you typed `System.Environment.getEnvironment` into GHCi 7.6? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9480#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler