#10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by haasn: Old description:

When trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module:

{{{ λ cabal build Building vimus-0.2.1... Preprocessing library vimus-0.2.1... [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: failed to map segment from shared object

Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}}

I don't know why it's only this particular module of this particular library that fails.

I'm running a kernel with GrSecurity and PaX enabled, and am using a hardened GCC toolchain (although Gentoo seems to automatically disable PIE for Haskell packages).

New description: When trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module: {{{ λ cabal build Building vimus-0.2.1... Preprocessing library vimus-0.2.1... [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: failed to map segment from shared object Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know why it's only this particular module of this particular library that fails. I'm running a kernel with GrSecurity and PaX enabled, and am using a hardened GCC toolchain (although Gentoo seems to automatically disable PIE for Haskell packages). That said, I checked ‘dmesg’ and there's no occurrence of a grsec exception. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10761#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by haasn): Seems to be related to template haskell. Removing the QuasiQuotes extension (and the lines that rely on it) makes it build successfully. I haven't been able to construct a minimal reproduction, though, even one that uses QuasiQuotes. So I'm not sure what else is needed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10761#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by haasn): I figured out how to trigger whether or not that sample fails: It works if I switch to the “vanilla” GCC profile (x86_64-pc-linux- gnu-4.9.3-vanilla, which has no hardening options enabled). It fails if I switch to the “hardened” GCC profile , even if I pick a version that has PIE and SSP disabled by default (x86_64-pc-linux- gnu-4.9.3-hardenednopiessp). So this particular failure, apart from potentially being a bug in either vimus or Cabal, is also triggered by the usage of hardened GCC. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10761#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Ultimately Cabal is doing something fragile here, by invoking ghc on only the Haskell sources, and not passing it the C sources or object files. If the Haskell source contains a Template Haskell splice that actually uses a function defined in a C source file then this can't possibly ever work. If there is a Template Haskell splice that uses another module from the current package that also happens imports a function from a C source file, this might work depending on the details of the linker. The temporary shared object loaded to run the splice will certainly contain an undefined symbol, but this may or may not be a problem. Relevant factors include * Whether the library is marked for lazy binding of functions (PLT references). If the binding is lazy, then the load will not fail and the Template Haskell splice runner will be able to use the shared library as long as it does not actually need to call the function in question. If the binding is not lazy then the load will fail (`Loading temp shared object failed: [...] undefined symbol: [...]`). Lazy binding is normally the default but in some hardened systems or build environments such as haasn's it is not. * Whether the foreign call refers to the C symbol by a PLT or GOT entry. GOT entries cannot be resolved at call time because the reference is not necessarily a call. Why would we call a C function through a GOT entry? Well if optimizations are not enabled then the code generator for an STG foreign call produces Cmm like {{{ _cJW::I64 = foobarbaz; call "ccall" arg hints: [] result hints: [] (_cJW::I64)(); }}} and to the backend this looks like a general reference to an object followed by an indirect function call. We can and probably should fix this but it doesn't fix the actual issue here. In my opinion it would make more sense for Cabal to just provide the C sources or object files to the ghc invocation. But also see https://github.com/haskell/cabal/issues/1738 which points out a problem with that idea. Should Cabal have two categories of C source files, one that consists of dependencies of the Haskell code and one that consists of source files that have foreign export stub headers as dependencies? I would think that since Cabal is intended for building Haskell libraries that the first category would be much greater... I don't know if it makes sense to do anything here in GHC besides being aware of the issue and setting `ghc-options: -optl-Wl,z,lazy` when building on systems where it is not the default as a workaround. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10761#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler