Neil Jerram <n...@ossau.uklinux.net> writes:
> Neil Jerram <n...@ossau.uklinux.net> writes:
>
>> My nightly build of master, on a relatively slow old machine, is
>> hanging, on most nights, in `make check'.
>
> FWIW, I realized that my backtraces are very similar to those reported
> by Dale here:
> http://www.mail-archive.com/bug-gu...@gnu.org/msg05066.html.
I think I have a reliable workaround for this, attached below. My
nightly build will now use this patch, and hopefully that'll mean that
it reliably produces benchmark data again.
The hang seems to be caused by one thread (A) running (gc) at the same
time as another thread (B) is doing GC_malloc_atomic. The third thread
in the backtrace is the signal delivery thread, and not involved.
But in the "mutex with owner not retained (bug #27450)" test there is no
thread B, so where does it come from? It's left over from the "locking
mutex on behalf of other thread" test, two tests previously. Adding
(join-thread t) to that earlier test means that the thread has to run
and complete before we get to the (gc) test.
My libgc is Debian version 1:7.1-3, so possibly this is a known libgc
issue that's already fixed upstream; I haven't tried to check that yet.
Regards,
Neil
>From 6013922c08c35a4e1051d4481d5bb4580bda1430 Mon Sep 17 00:00:00 2001
From: Neil Jerram <n...@ossau.uklinux.net>
Date: Thu, 23 Sep 2010 23:13:39 +0100
Subject: [PATCH] Workaround for hang in threads.test
---
test-suite/tests/threads.test | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/test-suite/tests/threads.test b/test-suite/tests/threads.test
index 58a2eba..234fb73 100644
--- a/test-suite/tests/threads.test
+++ b/test-suite/tests/threads.test
@@ -358,7 +358,9 @@
(let* ((m (make-mutex))
(t (begin-thread 'foo)))
(lock-mutex m #f t)
- (eq? (mutex-owner m) t)))
+ (let ((result (eq? (mutex-owner m) t)))
+ (join-thread t)
+ result)))
(pass-if "locking mutex with no owner"
(let ((m (make-mutex)))
--
1.7.1
