pthread mutex error building 6.10 on NetBSD
I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into an error, where cabal-bin calls the stage2 ghc in utils/installPackage. pthread_mutex_unlock() is called, evidently from fileLock(), with an invalid mutex. NetBSD's pthread implementation differs from Linux in its intolerance of such things. I have found errors where someone forgets that a mutex was never used and tries to unlock it. I guess you could do that all day long on Linux without noticing anything, but NetBSD aborts the program. In the present case, I don't see anything like that wrong in rts/FileLock.c, though. I'm stumped. So I'm checking, has anyone else built 6.10 on NetBSD? Donn
On Wed, Dec 31, 2008 at 10:44:07PM -0800, Donn Cave wrote:
I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into an error, where cabal-bin calls the stage2 ghc in utils/installPackage.
pthread_mutex_unlock() is called, evidently from fileLock(), with an invalid mutex.
NetBSD's pthread implementation differs from Linux in its intolerance of such things. I have found errors where someone forgets that a mutex was never used and tries to unlock it. I guess you could do that all day long on Linux without noticing anything, but NetBSD aborts the program. In the present case, I don't see anything like that wrong in rts/FileLock.c, though. I'm stumped.
So I'm checking, has anyone else built 6.10 on NetBSD?
Only on OpenBSD, and there it builds fine (when bootstrapping from either ghc-6.6 or -6.10). But what's interesting is that in includes/OSThreads.h the return values of pthread_mutex_lock(3) and pthread_mutex_unlock(3) aren't checked except apparently on Linux when building with DEBUG defined. You could either try to build with LOCK_DEBUG defined, so you see exactly when a lock is acquired and released, or try to build with DEBUG defined and that `&& defined(linux_HOST_OS)' removed from OSThreads.h to see what's going wrong. BTW: is there any pthread implementation still in the wild where pthread_mutex_{,un}lock() does NOT indicate a deadlock by EDEADLK? If not, the DEBUG part of OSThreads.h could be used for all systems, not only Linux. Ciao, Kili -- A typo a day, keeps the dictionnary away. -- Miod Vallat
Hi, On Thu, Jan 01, 2009 at 11:46:31AM +0100, Matthias Kilian wrote:
pthread_mutex_unlock() is called, evidently from fileLock(), with an invalid mutex.
NetBSD's pthread implementation differs from Linux in its intolerance of such things. I have found errors where someone forgets that a mutex was never used and tries to unlock it. I guess you could do that all day long on Linux without noticing anything, but NetBSD aborts the program. In the present case, I don't see anything like that wrong in rts/FileLock.c, though. I'm stumped.
So I'm checking, has anyone else built 6.10 on NetBSD?
Could you (and anyone else on any operating system using pthreads)
please try to build with the patch below? It checks the return
values of pthread_mutex_lock() and pthread_mutex_unlock() by default
(even if DEBUG isn't defined) and contains some other uncluttering.
Seems to work fine here on OpenBSD (for ghc-head), but before I
send out a darcs patch, I'd like to see some results on other
systems.[1]
Of course, the patch won't fix the problem for NetBSD, but it may
give some more hints.
Ciao,
Kili
[1] and if you insist in darcs patches, just pull from
http://darcs.volkswurst.de/users/kili/ghc-6.10/ghc/ or
http://darcs.volkswurst.de/users/kili/ghc/
diff -x _darcs -rNup ../ghc/includes/OSThreads.h ./includes/OSThreads.h
--- ../ghc/includes/OSThreads.h Sun Jan 4 22:28:46 2009
+++ ./includes/OSThreads.h Sun Jan 4 22:11:34 2009
@@ -23,6 +23,7 @@
#else
#include
participants (2)
-
Donn Cave -
Matthias Kilian