---- "Ludovic Courtès" <l...@gnu.org> wrote: > Hi Dale,
Greetings. Thanks for taking a look. And for adding a Subject: (oops!) > An easy answer, but there’s some truth in it: > > <dsm...@roadrunner.com> writes: > > > With guile at v2.0.0-134-g38c50a9, I'm getting a couple of failures in > > threads.test on my single core Debian Squeeze machine: > > > > FAIL: threads.test: lock-mutex: timed locking succeeds if mutex unlocked > > within timeout > > This one may be sensitive to load. Can you try changing > (+ (current-time) 2) to (+ (current-time) 5)? Still failing. Ok I take that back. There was two places with (+ (current-time) 2). After changing the other one it is *not* failing. diff --git a/test-suite/tests/threads.test b/test-suite/tests/threads.test index 2ffffb5..ba0a2a1 100644 --- a/test-suite/tests/threads.test +++ b/test-suite/tests/threads.test @@ -213,7 +213,7 @@ (signal-condition-variable c) (unlock-mutex cm) (lock-mutex m - (+ (current-time) 2)))))) + (+ (current-time) 5)))))) (lock-mutex m) (wait-condition-variable c cm) (unlock-mutex cm) > > FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug > > #27450) > > This one is GC-sensitive. It’s already kludged at length to improve the > chances of success, but I don’t know how to improve the situation. It > could throw unresolved instead of failing, but that doesn’t really > help... This message I think I never see when running the test directly. Only with "make check" do I see it. Yeah, three times in a row with make check, never with ./check-guile threads.test. I'm running 7.2alpha5 libgc. From that tarball I think, not cvs. -Dale