segfault with GHC.Handle.fdToHandle'

[EricKow]

While trying to configure darcs, a FreeBSD user discovered that the following program segfaults if you compile it with "ghc -threaded -optl-L/usr/local/lib -optl-L/usr/local/lib/ -optl-pthread"

import GHC.Handle ( fdToHandle' )
import IO ( IOMode(..) )

main = fdToHandle' 1 Nothing False "stdout" WriteMode True

For more details, please see  http://bugs.darcs.net/issue979

[igloo]

I can't reproduce this on Linux/amd64.

[obraun]

I can't reproduce this on FreeBSD/i386. I am currently setting up a FreeBSD/amd64 machine to check it on that platform.

[obraun]

I can't reproduce this on FreeBSD/amd64, too.

[obraun]

My previous comments are valid for FreeBSD 7.x. I was able to reproduce this on FreeBSD 6.3, which is a _legacy_ release. Unfortunately, I have not enough time at the moment to track this down. Anyway, since FreeBSD 6 is only a legacy release and will be EOL in the near future, we can probably ignore this bug for the next ghc release.

[simonmar]

Moving it out of the 6.10.1 milestone, as per Olli's comment.

[thorkilnaur]

With

$ uname -a
FreeBSD tn12.thorkilnaur.dk 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007     root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$

I can do

$ cat t1.hs
import GHC.Handle ( fdToHandle' )
import IO ( IOMode(..) )

main = fdToHandle' 1 Nothing False "stdout" WriteMode True
$ ghc -fforce-recomp --make t1.hs -threaded
[1 of 1] Compiling Main             ( t1.hs, t1.o )
Linking t1 ...
$ ./t1
$ ghc -fforce-recomp --make t1.hs -threaded -optl-pthread
[1 of 1] Compiling Main             ( t1.hs, t1.o )
Linking t1 ...
$ ./t1
Segmentation fault: 11 (core dumped)
$

Studying the gcc and ld command lines produced by ghc using -v, I find that -optl-pthread (as one would expect) adds -pthread to the gcc command for performing the link. This, in turn, causes -lpthread to be added to the ld command. Now, the ld command already has -lthr which prompted a search which uncovered  http://planet.gentoo.org/developers/lavajoe/2007/09/17/spinning_my_tires_in_bug_mud. According to Joe Peterson in this reference, libthr is the newer FreeBSD threading library, replacing the older libpthread. And, again according to the quoted reference, at least in older FreeBSDs (like the 6.2 I am using here), mixing the two could lead to segmentation faults, in spite of libpthread being "mapped to libthr by libmap.conf".

Summing all this up, I would say that this is a FreeBSD problem, not a GHC problem. And, of course, the work-around is not to use the -optl-pthread flag, which doesn't appear to be necessary in any case. So I suggest that we close this ticket.

Best regards Thorkil