reducing the code to:
use nqp;
my $lock = Lock.new;
my $hash := nqp::hash;
await ^16 .map: {
start {
for ^1000 {
$lock.protect: { nqp::bindkey($hash,"a",1) }
$lock.protect: { nqp::deletekey($hash,"a") }
}
}
}
does *not* make it crash. So it would appear that it’s not the lowlevel hash
access that’s to blame. Looking at this with Telemetry.snapper, this *does*
seem to eat a lot of memory very quickly. With a slightly bigger version, and
much longer running, growth to about 490MB is observed (starting from 69MB) in
35 seconds, then remaining constant for about 125 seconds, after which a modest
increase of only about 15KB per second was observed for the remainder of the
run.
So the next maybe it’s something in handling Proxy.
> On 10 Nov 2017, at 03:28, David Lowe <[email protected]> wrote:
>
> This crash still occurs with rakudo 2017.10.
>
> On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT <[email protected]>
> wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "segmentation fault while concurrently updating SetHash",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket has been
> assigned an ID of [perl #132225].
>
> Please include the string:
>
> [perl #132225]
>
> in the subject line of all future correspondence about this issue. To do so,
> you may reply to this message.
>
> Thank you,
> [email protected]
>
> -------------------------------------------------------------------------
> This short program crashes reliably (with a segmentation fault) on my
> system:
>
> ```
> #!/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 }
> }
> }
> }
> ```
>
> More information:
>
> ```
> $ perl6 --version
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.
> ```
>
>
