Segmentation fault in non-dynamically linked binaries?

Tue Jun 15 06:33:26 EDT 2010

On 13/06/2010 07:26, austin seipp wrote:
> Hello,
>
> I am running GHC on x86_64 debian linux, and recently I have
> discovered that the executables generated by my GHC segfault when the
> linking step is not dynamic.
> I discovered this while attempting to install haskell-src-exts, which
> requires a linked version of Setup.hs when cabal builds it (and which
> would fail inexplicably until I did
> further investigation.)
>
> Example:
>
> link ~/t » cat hi.hs
> main :: IO ()
> main = putStrLn "hi"
> link ~/t » ghc -dynamic hi.hs
> link ~/t » file ./a.out
> ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
> link ~/t » ldd ./a.out
> 	linux-vdso.so.1 =>   (0x00007fffbadff000)
> 	libHShaskell98-1.0.1.1-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/haskell98-1.0.1.1/libHShaskell98-1.0.1.1-ghc6.12.3.so
> (0x00007fab3a4c4000)
> 	libHSrandom-1.0.0.2-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/random-1.0.0.2/libHSrandom-1.0.0.2-ghc6.12.3.so
> (0x00007fab3a2af000)
> 	libHStime-1.1.4-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/time-1.1.4/libHStime-1.1.4-ghc6.12.3.so
> (0x00007fab39fad000)
> 	libHSprocess-1.0.1.3-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/process-1.0.1.3/libHSprocess-1.0.1.3-ghc6.12.3.so
> (0x00007fab39d93000)
> 	libHSdirectory-1.0.1.1-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/directory-1.0.1.1/libHSdirectory-1.0.1.1-ghc6.12.3.so
> (0x00007fab39b77000)
> 	libHSunix-2.4.0.2-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/unix-2.4.0.2/libHSunix-2.4.0.2-ghc6.12.3.so
> (0x00007fab398c6000)
> 	librt.so.1 =>  /lib/librt.so.1 (0x00007fab396a2000)
> 	libutil.so.1 =>  /lib/libutil.so.1 (0x00007fab3949f000)
> 	libdl.so.2 =>  /lib/libdl.so.2 (0x00007fab3929b000)
> 	libHSold-time-1.0.0.5-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/old-time-1.0.0.5/libHSold-time-1.0.0.5-ghc6.12.3.so
> (0x00007fab3903c000)
> 	libHSold-locale-1.0.0.2-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/old-locale-1.0.0.2/libHSold-locale-1.0.0.2-ghc6.12.3.so
> (0x00007fab38e28000)
> 	libHSfilepath-1.1.0.4-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/filepath-1.1.0.4/libHSfilepath-1.1.0.4-ghc6.12.3.so
> (0x00007fab38c07000)
> 	libHSarray-0.3.0.1-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/array-0.3.0.1/libHSarray-0.3.0.1-ghc6.12.3.so
> (0x00007fab38992000)
> 	libHSbase-4.2.0.2-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/base-4.2.0.2/libHSbase-4.2.0.2-ghc6.12.3.so
> (0x00007fab381f2000)
> 	libHSinteger-gmp-0.2.0.1-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/integer-gmp-0.2.0.1/libHSinteger-gmp-0.2.0.1-ghc6.12.3.so
> (0x00007fab37fe1000)
> 	libgmp.so.3 =>  /usr/lib/libgmp.so.3 (0x00007fab37da1000)
> 	libHSghc-prim-0.2.0.0-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so
> (0x00007fab37b1c000)
> 	libHSrts-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/libHSrts-ghc6.12.3.so (0x00007fab378ba000)
> 	libm.so.6 =>  /lib/libm.so.6 (0x00007fab37637000)
> 	libHSffi-ghc6.12.3.so =>
> /usr/local/lib/ghc-6.12.3/libHSffi-ghc6.12.3.so (0x00007fab3742a000)
> 	libc.so.6 =>  /lib/libc.so.6 (0x00007fab370c9000)
> 	libpthread.so.0 =>  /lib/libpthread.so.0 (0x00007fab36eac000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007fab3a6cb000)
> link ~/t » ./a.out
> hi
> link ~/t » rm ./a.out *.hi *.o
> link ~/t » ghc hi.hs
> link ~/t » file ./a.out
> ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
> link ~/t » ldd ./a.out
> 	linux-vdso.so.1 =>   (0x00007fffaafff000)
> 	librt.so.1 =>  /lib/librt.so.1 (0x00007fdf83d77000)
> 	libutil.so.1 =>  /lib/libutil.so.1 (0x00007fdf83b74000)
> 	libdl.so.2 =>  /lib/libdl.so.2 (0x00007fdf8396f000)
> 	libgmp.so.3 =>  /usr/lib/libgmp.so.3 (0x00007fdf83730000)
> 	libm.so.6 =>  /lib/libm.so.6 (0x00007fdf834ae000)
> 	libc.so.6 =>  /lib/libc.so.6 (0x00007fdf8314c000)
> 	libpthread.so.0 =>  /lib/libpthread.so.0 (0x00007fdf82f30000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007fdf83f9c000)
> link ~/t » ./a.out
> [1]    7850 segmentation fault  ./a.out
> link ~/t » gdb7.0 ./a.out
>
>
>                                                        139 ↵
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later<http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/a/t/a.out...done.
> (gdb) r
> Starting program: /home/a/t/a.out
> [Thread debugging using libthread_db enabled]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000067b3c0 in strlen@@GLIBC_2.2.5 ()
> (gdb) bt
> #0  0x000000000067b3c0 in strlen@@GLIBC_2.2.5 ()
> #1  0x0000000000432dd7 in setFullProgArgv ()
> #2  0x000000000043464d in hs_init ()
> #3  0x000000000043478d in startupHaskell ()
> #4  0x0000000000433d59 in real_main ()
> #5  0x0000000000433e87 in hs_main ()
> #6  0x00007ffff6fccc4d in __libc_start_main () from /lib/libc.so.6
> #7  0x0000000000402d49 in _start ()
> (gdb)
>
>
> What's interesting is that this occurs with all versions of GHC on my
> machine, which include:
>   * GHC 6.12.1
>   * GHC 6.12.3
>   * GHC 6.13.20100426
>
> Executables that were statically linked with GHC before this strange
> behavior started occurring appear to still work, i.e. xmonad&  xmobar.
> I recently did an update of my machine with aptitude, but I would not
> think this would interfere with GHC.

Strange - I suspect there is some ABI change in glibc that means the 
static libraries are no longer compatible with the new version.  You'll 
get more information out of gdb if you compile with -debug, then try 
stepping through from setFullProgArgv to see what goes wrong.

If there is an ABI change, and it's going to appear in all the major 
Linux distros at some point, this could give us some difficulties with 
binary distributions.

Cheers,
	Simon