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 <j.david.l...@gmail.com> wrote: > > This crash still occurs with rakudo 2017.10. > > On Thu, Oct 5, 2017 at 9:10 PM, perl6 via RT <perl6-bugs-follo...@perl.org> > 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, > perl6-bugs-follo...@perl.org > > ------------------------------------------------------------------------- > 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. > ``` > >