Segmentation fault in non-dynamically linked binaries?

austin seipp as at 0xff.ath.cx
Sun Jun 13 02:26:59 EDT 2010


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.

Does anybody have any ideas?


More information about the Glasgow-haskell-users mailing list