Skip to content
Snippets Groups Projects

TH segmentation fault on Linux when calling function from another package

    • Open Issue created by jmaki @trac-jmaki

    The bug was hit when using Buck (buckbuild.com) to build. I had two packages, A containing a single module with a TH function of type TH.Q [TH.Dec] and module B importing A it and calling that function at top-level. I've attached a tarball that reproduces the problem using just 'ghc', 'ghc-pkg' and 'ar'.

    I've verified that the problem occurs with 7.10.3, 8.0.2 and a semi-recent GHC HEAD from @bitonic. The issue doesn't occur on macOS and does not occur when the modules are in a single package or if the package is compiled as a shared library. The problem also does not occur when using stack, so this is likely related to how buck creates packages.

    Edited by jmaki
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • jmaki changed weight to 5

      changed weight to 5

    • jmaki added Tbug Trac import labels

      added Tbug Trac import labels

    • jmaki
      jmaki @trac-jmaki ·
      Author

      Attached file repro.tar.gz (download).

    • jmaki changed the description

      changed the description

    • jmaki
      jmaki @trac-jmaki ·
      Author
    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      Thanks for the repro!

      There is definitely something fishy here. GDB says,

      Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007f631235ed30 in base_GHCziBase_return_info () from /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/bin/../base-4.10.0.0/libHSbase-4.10.0.0-ghc8.3.20170329.so
(rr) bt
#0  0x00007f631235ed30 in base_GHCziBase_return_info () from /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/bin/../base-4.10.0.0/libHSbase-4.10.0.0-ghc8.3.20170329.so
#1  0x0000000000000000 in ?? ()
(rr)

      passing +RTS -Dl we get the following forboding warnings,

      ...
Rel entry   4 is raw(  0x54 0x160000000b  (nil))   lookupSymbol: looking up stg_ap_p_info
lookupSymbol: value of stg_ap_p_info is 0x7f63112740c8
`stg_ap_p_info' resolves to 0x7f63112740c8
Reloc: P = 0x401311ec   S = 0x7f63112740c8   A = (nil)
Rel entry   5 is raw(  0x5c 0x170000000b    0x1)   lookupSymbol: looking up ghczmprim_GHCziTypes_ZMZN_closure
lookupSymbol: symbol not found
`ghczmprim_GHCziTypes_ZMZN_closure' resolves to 0x7f6311b41d50
Reloc: P = 0x401311f4   S = 0x7f6311b41d50   A = 0x1
Rel entry   6 is raw(  0x65 0x1800000002 0xfffffffffffffffc)   lookupSymbol: looking up base_GHCziBase_return_info
lookupSymbol: symbol not found
`base_GHCziBase_return_info' resolves to 0x7f631235ed10
Reloc: P = 0x401311fd   S = 0x7f631235ed10   A = 0xfffffffffffffffc
relocations for section 3 using symtab 11
Rel entry   0 is raw( (nil) 0xe00000001  (nil))   lookupSymbol: looking up ghczmprim_GHCziTypes_TrNameS_con_info
lookupSymbol: symbol not found
`ghczmprim_GHCziTypes_TrNameS_con_info' resolves to 0x7f63118655c0
Reloc: P = 0x40131208   S = 0x7f63118655c0   A = (nil)
...

      Looking at the libHSbase archive, we see,

      $ objdump -x /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/base-4.10.0.0/libHSbase-4.10.0.0.a | less
...
SYMBOL TABLE:
...
0000000000000000         *UND*  0000000000000000 base_GHCziBase_return_info

      Very interesting.

    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      In contrast, the monolithic object file contains the symbol,

      $ objdump -x /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/base-4.10.0.0/HSbase-4.10.0.0.o  | less
...
SYMBOL TABLE:
...
00000000001b1150 g     O .text  0000000000000045 base_GHCziBase_return_info
    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      Hmmm, looking back at GHC/Base.o,

      $ objdump -x /opt/exp/ghc/ghc-master/libraries/base/dist-install/build/GHC/Base.o | less
...
SYMBOL TABLE:
...
0000000000000050 l       .text.base_GHCziBase_zgzg_info 0000000000000000 c5Mf_info
0000000000000000 l    d  .data.base_GHCziBase_return_closure    0000000000000000 .data.base_GHCziBase_return_closure
0000000000000000 l    d  .text.base_GHCziBase_return_info       0000000000000000 .text.base_GHCziBase_return_info
0000000000000050 l       .text.base_GHCziBase_return_info       0000000000000000 c5Mx_info
0000000000000000 l    d  .data.base_GHCziBase_fail_closure      0000000000000000 .data.base_GHCziBase_fail_closure
0000000000000000 l    d  .text.base_GHCziBase_fail_info 0000000000000000 .text.base_GHCziBase_fail_info
...
0000000000000018 g     O .text.base_GHCziBase_zgzg_info 0000000000000045 base_GHCziBase_zgzg_info
0000000000000000 g     O .data.base_GHCziBase_return_closure    0000000000000000 base_GHCziBase_return_closure
0000000000000018 g     O .text.base_GHCziBase_return_info       0000000000000045 base_GHCziBase_return_info
0000000000000000 g     O .data.base_GHCziBase_fail_closure      0000000000000000 base_GHCziBase_fail_closure
    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      One interesting observation is that there are two modules named Base.o that get placed in the archive file,

      $ ar t dist-install/build/libHSbase-4.10.0.0.a | grep Base
Base.o
Base.o

      One of these is GHC.Base and the other is Control.Exception.Base. Given that ar --print-armap reports base_GHCziBase_return_info as defined I wonder whether the RTS linker fails to find the symbol due to this repeated object name.

    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      Regarding ticket:13501#comment:134275: I suspect not given that this is a dynamic GHC; in fact, I believe GHC shouldn't actually load **any** objects for base since it is one of the packages in Linker.partOfGHCi. I have confirmed that base_GHCziBase_return_info is present in the libHSbase shared object.

      Nevertheless, it might be good to circle back and look into the archive oddness seen in ticket:13501#comment:134272 after nailing this bug.

    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      So the symbols in question are indeed being resolved by the dynamic linker (using the "main program" handle).

    • jmaki
      jmaki @trac-jmaki ·
      Author

      Switching to link-style 'static_pic' in buck fixes the issue. Difference to "repro":

      -ghc -no-link -package-name foo -i Foo.hs -Wall -Werror
+ghc -fPIC -dynamic -hisuf dyn_hi -no-link -package-name foo -i Foo.hs -Wall -Werror

-ghc -no-link -package-name bar -package-db ../foo/pkg -package foo \
+ghc -fPIC -dynamic -no-link -package-name bar -package-db ../foo/pkg -package foo-1.0.0 \
    Bar.hs
    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      Well, that essentially confirms that the issue is related to dynamic linking.

    • trac-import added compiler crash label

      added compiler crash label

    • Ben Gamari added Pnormal label

      added Pnormal label

    Please register or sign in to reply