bug#10647: Guile 2.0.3: fails make check on s390 in threads.test

bug#10647: Guile 2.0.3: fails make check on s390 in threads.test

[Rob Browning]

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

bug#10647: Guile 2.0.3: fails make check on s390 in threads.test

[Ludovic Courtès]

Hi Rob,

Rob Browning <rlb@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’.

bug#10647: Guile 2.0.3: fails make check on s390 in threads.test

[Noah Lavine]

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@gnu.org> wrote:
> Hi Rob,
>
> Rob Browning <rlb@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’.
>
>
>

bug#10647: Guile 2.0.3: fails make check on s390 in threads.test

[Ludovic Courtès]

Hi!

Noah Lavine <noah.b.lavine@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’.