GNU bug report logs - #10647
Guile 2.0.3: fails make check on s390 in threads.test

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10647 in the body.
You can then email your comments to 10647 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rob Browning <rlb <at> defaultvalue.org>
To: submit <at> debbugs.gnu.org
Subject: Guile 2.0.3: fails make check on s390 in threads.test
Date: Sun, 29 Jan 2012 21:36:28 -0600

Package: Guile
Version: 2.0.3

Make check fails on the s390x architecture:

  FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)

You can see the full build log here:

  https://buildd.debian.org/status/fetch.php?pkg=guile-2.0&arch=s390&ver=2.0.3%2B1-3&stamp=1327882482

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Message #10 received at 10647-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Rob Browning <rlb <at> defaultvalue.org>
Cc: 10647-done <at> debbugs.gnu.org
Subject: Re: bug#10647: Guile 2.0.3: fails make check on s390 in threads.test
Date: Mon, 03 Sep 2012 22:52:24 +0200

Hi Rob,

Rob Browning <rlb <at> defaultvalue.org> skribis:

>   FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)

This one is harmless, and can be ignored.  It’s a consequence of using a
conservative GC, which is non-deterministic.

So closing this bug (and looking at the others, yes! ;-)).

Thanks,
Ludo’.

Message #13 received at 10647 <at> debbugs.gnu.org (full text, mbox):

From: Noah Lavine <noah.b.lavine <at> gmail.com>
To: 10647 <at> debbugs.gnu.org, ludo <at> gnu.org
Cc: 10647-done <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#10647: Guile 2.0.3: fails make check on s390 in threads.test
Date: Tue, 4 Sep 2012 20:22:46 -0400

Hello,

I'm not an expert on GC, but I've seen similar issues pop up several
times. Apparently there is at least one (and I suspect several) Guile
tests whose outputs are nondeterministic. If so, could we make those
tests always succeed?

I say this because I imagine it is very confusing for users who don't
know what's happening to see a test fail, and still have a working
Guile. It might also confuse smart build systems like Nix that check
for test failures. :-)

I said make it always succeed, rather than remove it, because it is
still important for developers who know what's going on to be able to
run it and get some sort of output. Alternatively, the test could be
to run the same program several times and return true if some high
proportion of the runs succeeded. That would at least cut down on the
number of false negatives.

Noah

On Mon, Sep 3, 2012 at 4:52 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Hi Rob,
>
> Rob Browning <rlb <at> defaultvalue.org> skribis:
>
>>   FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)
>
> This one is harmless, and can be ignored.  It’s a consequence of using a
> conservative GC, which is non-deterministic.
>
> So closing this bug (and looking at the others, yes! ;-)).
>
> Thanks,
> Ludo’.
>
>
>

Message #19 received at 10647 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Noah Lavine <noah.b.lavine <at> gmail.com>
Cc: 10647 <at> debbugs.gnu.org, 10647-done <at> debbugs.gnu.org,
	Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#10647: Guile 2.0.3: fails make check on s390 in threads.test
Date: Wed, 05 Sep 2012 22:23:21 +0200

Hi!

Noah Lavine <noah.b.lavine <at> gmail.com> skribis:

> I'm not an expert on GC, but I've seen similar issues pop up several
> times. Apparently there is at least one (and I suspect several) Guile
> tests whose outputs are nondeterministic. If so, could we make those
> tests always succeed?

Yes, almost all GC-related tests are non-deterministic.  Some are more
likely to fail on 32-bit arches, too.  I agree this can be confusing.

In the past, some of these tests were changed to throw to 'unresolved
instead of failing.  This addresses the issue by not alerting users for
non-issues.  As a side effect, we basically ignore these tests, which
isn’t good either.

So I’d try to be caution and only move from fail to unresolved those
tests, for which we routinely observe random failures.  On my laptop and
on Hydra, none of these tests fails, neither on x86_64 nor on i686, so
I’d be inclined to let them as is.

WDYT?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.