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 ...
