It's a bit tricky to get a proper backtrace dump out of gdb for this, but what I'm seeing is this:
this source file calls sink on a value from outside the protected lock, which runs the FETCH of the SetHash, which calls nqp::existskey on the internal elems hash. That part is explosive, presumably because setting a value to False in SetHash removes it from the underlying hash. Not sure how to fix this bug properly. Could be "just" called a trap, but it's a real nasty one. Once hashes have been ported over to a non-crashy version (i.e. not immediately freeing storage when the hash is resized) this will probably just get inconsistent results in whether it'll sink a true or a false. On 11/10/17 08:06, Timo Paulssen via RT wrote: > This runs reliably when you let the lock-protected block return > something unrelated to the hash: > > #!/usr/bin/env perl6 > > use v6.c; > > my $lock = Lock.new; > my $set = SetHash.new; > await (^12).map: { > start { > for (^1000) { > $lock.protect: { $set<1> = True } > $lock.protect: { $set<1> = False } > } > } > } > > > My assumption is that it has something to do with sinking the Bool we're > assigning outside the lock-protected block, but printing the .VAR of > what it returns is really just a Bool object ...