Re: GHC 6.4.3 on FreeBSD
For the time being, I've committed a change that forces GHC to use -lthr on FreeBSD instead of whatever the default is (usually libpthread). This works around the hangs for me. If someone else on FreeBSD could verify this, I'd be grateful. You need to check out the 6.4 branch from CVS: $ cvs co -r ghc-6-4-branch fpconfig $ cd fptools $ cvs up -d hslibs libraries ghc testsuite Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4.3 on FreeBSD (fwd)
Dear [EMAIL PROTECTED] (and others), This is relating to the problems we're experiencing with GHC's threaded runtime on FreeBSD (see context below). GHC itself, which is a Haskell program, when compiled with itself and linked against GHC's threaded runtime, sometimes hangs eating 100% CPU. This happens when it is linked with -pthreads, I haven't seen it when linking with -lthr. If I attach using gdb to a hung process, I see this: (gdb) where #0 0x2897146b in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x28972499 in __error () from /usr/lib/libpthread.so.2 #2 0x2895e6ba in sigaction () from /usr/lib/libpthread.so.2 #3 0x087ea6b4 in runProcess (args=0x29091758, workingDirectory=0x0, environment=0x0, fdStdInput=0, fdStdOutput=1, fdStdError=2, set_inthandler=1, inthandler=0, set_quithandler=1, quithandler=0) at runProcess.c:61 #4 0x0879b3d0 in s3ja_info () Now, runProcess() is part of our libraries. It is basically doing a fork/exec combo, with some sigaction()s and other stuff in between. As I understand the POSIX spec, it should be safe to do sigaction() in the child of a fork() in a multithreaded process. So I'm surprised to see pthread_testcancel on the stack there. This is about all I've managed to extract. gdb is having difficulty looking at the other threads: (gdb) info thr * 5 LWP 100331 0x2897146b in pthread_testcancel () from /usr/lib/libpthread.so.2 4 Thread 0x892 (LWP 100278) Cannot get lwp 100278 registers: Operation not permitted for unknown reasons. Any help would be appreciated... Cheers, Simon On 07 August 2006 18:31, Robert Watson wrote: Dear many, I pinged the FreeBSD threads list about the previously mentioned problem, and was sent this patch by Dan Eischen. The FreeBSD threads mailing list is extremely responsive to bug reports; my recommendation is that we direct future specific bug reports, as well as any feedback on this patch, to that list. Thanks, Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Mon, 7 Aug 2006 13:15:21 -0400 (EDT) From: Daniel Eischen [EMAIL PROTECTED] To: Robert Watson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: GHC 6.4.3 on FreeBSD (fwd) On Mon, 7 Aug 2006, Robert Watson wrote: I've been talking to the Haskell folk about problems they've had getting their threaded runtime running on FreeBSD. Here's one of their problem reports. Since I'm not up on how threads and signals are supposed to act, I can't confirm the below is a bug, of course, but figured you (experts) would be able to respond better. Try this patch. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4.3 on FreeBSD (fwd)
Thanks Robert. I don't believe that particular bug is on our critical path, but I'm glad they have a fix. I haven't tried the patch myself, not having a FreeBSD build handy. The current status w.r.t. GHC is: - I merged a fix to the timeout program in our testsuite that fixes occasional hangs on FreeBSD (issue was calling fork() from the child of fork(), not allowed according to POSIX). - I did a complete build and testsuite run with -lthr instead of -pthread, this completes without problems. - When GHC itself is linked with the threaded RTS and -pthread, it occasionally hangs (I saw about 5 hangs during a testsuite run of 2000 tests). When it hangs, it is consuming 100% CPU. I tried attached to the hung GHC process using gdb, and got this: ~ gdb --pid=53978 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Attaching to process 53978 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c :1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c :1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Abort trap: 6 (core dumped) At this stage I'm tempted to default to using -lthr, since this appears to work. I can't make any further progress on the -pthread hangs without gdb working, unfortunately. If you think I should report the gdb crash, where is the best place? Cheers, Simon On 07 August 2006 18:31, Robert Watson wrote: Dear many, I pinged the FreeBSD threads list about the previously mentioned problem, and was sent this patch by Dan Eischen. The FreeBSD threads mailing list is extremely responsive to bug reports; my recommendation is that we direct future specific bug reports, as well as any feedback on this patch, to that list. Thanks, Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Mon, 7 Aug 2006 13:15:21 -0400 (EDT) From: Daniel Eischen [EMAIL PROTECTED] To: Robert Watson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: GHC 6.4.3 on FreeBSD (fwd) On Mon, 7 Aug 2006, Robert Watson wrote: I've been talking to the Haskell folk about problems they've had getting their threaded runtime running on FreeBSD. Here's one of their problem reports. Since I'm not up on how threads and signals are supposed to act, I can't confirm the below is a bug, of course, but figured you (experts) would be able to respond better. Try this patch. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.3 on FreeBSD
Simon Marlow wrote: An update on the GHC/FreeBSD front: I didn't manage to reproduce the reported threading bugs on a UP, will be trying on a MP shortly. Using -lthr instead of -pthread, I completed a test run on the dual proc box: OVERALL SUMMARY for test run started at Tue Aug 8 09:21:49 EDT 2006 1365 total tests, which gave rise to 6055 test cases, of which 0 caused framework failures 1034 were skipped 4944 expected passes 61 expected failures 4 unexpected passes 12 unexpected failures Unexpected passes: cholewo-eval(optasm,profasm) ffi009(optasm,profasm) Unexpected failures: barton-mangler-bug(normal,opt,prof,ghci,threaded) queryfdoption01(normal,opt,optasm,prof,profasm,threaded) rn.prog006(normal) Nothing to worry about here. I also discovered that we already have a fix in the HEAD's version of timeout that makes it work on FreeBSD (d'oh). The problem is that our timeout program forks and then calls system(), which forks again, and this is allegedly not allowed. I've merged that fix into STABLE now. I'm running the testsuite again with everything linked with -pthread and using the fixed timeout program. So far I haven't seen the other reported symptom, namely that the stage2 compiler sometimes hangs. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4.3 on FreeBSD
An update on the GHC/FreeBSD front: I didn't manage to reproduce the
reported threading bugs on a UP, will be trying on a MP shortly.
However, I did discover one odd case that libpthread doesn't appear to
handle properly, but libthr does. This arose from a test in GHC's test
suite, but I've transliterated the code from Haskell to C:
$ cat thr1.c
#include unistd.h
#include signal.h
#include pthread.h
int main(int argc, char *argv[])
{
sigset_t s;
sigemptyset (s);
sigaddset(s, SIGUSR1);
sigprocmask(SIG_BLOCK, s, NULL);
pthread_kill(pthread_self(), SIGUSR1);
sigpending(s);
printf(%x\n, s);
exit(0);
}
$ gcc -pthread thr1.c
$ ./a.out
0
$ gcc -lthr thr1.c
$ ./a.out
2000
$
This might (or might not) be related to the other threading issues with
GHC on FreeBSD.
Do you think we should link with -lthr by default on FreeBSD? This
would be a trivial change to make, and given that GHC has its own
lightweight threading runtime, we probably aren't getting much from
having the KSE-based threading implementation anyway.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
