FWIW, I couldn’t get this to fail on my MBP *while* running make spectest with TEST_JOBS=8
Perhaps this is OS / CPU / compiler dependent? > On 5 Sep 2017, at 09:17, Aleks-Daniel Jakimenko-Aleksejev via RT > <perl6-bugs-follo...@perl.org> wrote: > > Oh. A crude way to reproduce it is: > > while :; do clear; PERL6LIB=lib ./perl6-m t/spec/S17-lowlevel/atomic-ops.t || > break; done > > And just leave it running, it'll fail at some point. Get your system busy with > something and it'll fail faster. > > On 2017-09-05 00:14:11, alex.jakime...@gmail.com wrote: >> Here's the output when it fails: >> >> ok 1 - Can do an atomic fetch from a Scalar container >> ok 2 - Can do an atomic assign to a Scalar container; returns new >> value >> ok 3 - Atomic fetch after atomic assign shows latest value >> ok 4 - Updated value seen by non-atomic too >> 1..2 >> ok 1 - code dies >> ok 2 - right exception type (X::TypeCheck::Assignment) >> ok 5 - Cannot atomic assign value of the wrong type >> ok 6 - No hang due to incorrect lifting of atomic fetch out of loop >> ok 7 - Can do an atomic fetch from an int container >> ok 8 - Can do an atomic assign to an int container; returns new value >> ok 9 - Atomic int fetch after atomic int assign shows latest value >> ok 10 - Updated value seen by non-atomic too >> A IntLexRef container does not know how to do an atomic load >> in block <unit> at t/spec/S17-lowlevel/atomic-ops.t line 41 >> >> # Looks like you planned 28 tests, but ran 10 >> >> >> I noticed that it fails more often when the system is under load (e.g. >> when running the spectest). Other than that I don't have any info.
