[perl #127452] [CONC] hyper is very broken, *sometimes* it returns nothing
On Mon, 01 Feb 2016 21:59:33 -0800, alex.jakime...@gmail.com wrote:
> Let's try running the same code twice:
>
> m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: {
> sleep rand / 10; $_ + 1 }; say @y
> rakudo-moar a5fe34: OUTPUT«[]»
> m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: {
> sleep rand / 10; $_ + 1 }; say @y
> rakudo-moar a5fe34: OUTPUT«[1 2 3 4 5 6 7 8 9 10]»
>
> The thing is that sometimes ｢hyper｣ decides to return an empty list. This
> is a real problem because it basically renders it useless (too unreliable).
>
> If you have problems reproducing it, try changing ｢/ 10｣ to something
> else. This delay is not really relevant but it seems like it affects the
> chances to get one result or another.
>
> Here's also a golfed down version:
>
> Code:
> dd @(^10 .hyper(:1batch).map: { sleep rand; $_ })
>
> Result:
> ()
> OR
> (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
>
> According to the execution time ｢hyper｣ does not even bother to compute the
> result in these problematic cases (it just returns an empty list without
> trying to process the data). That being said, there is a chance that it
> fails half way through, see next example.
>
>
> Another interesting issue (probably the same one):
>
> Code:
> .say for (^10).hyper(:1batch).map: { sleep rand; $_ }
>
> Result:
> 1
> OR
> 2
> OR
> 3
> OR
> 0
> 3
> 2
> 1
> 5
> 8
> 7
> 4
> 6
> 9
> OR etc.
>
> So not only it is out of order (#127099), but it is also extremely broken.
>
> It looks like there is no such problem with ｢race｣.
>
> IRC log (nothing useful there though):
> http://irclog.perlgeek.de/perl6/2016-02-02#i_11975794
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t (for original post and other examples that I found in the
discussion of this ticket).
[perl #127452] [CONC] hyper is very broken, *sometimes* it returns nothing
On Mon, 01 Feb 2016 21:59:33 -0800, alex.jakime...@gmail.com wrote:
> Let's try running the same code twice:
>
> m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: {
> sleep rand / 10; $_ + 1 }; say @y
> rakudo-moar a5fe34: OUTPUT«[]»
> m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: {
> sleep rand / 10; $_ + 1 }; say @y
> rakudo-moar a5fe34: OUTPUT«[1 2 3 4 5 6 7 8 9 10]»
>
> The thing is that sometimes ｢hyper｣ decides to return an empty list. This
> is a real problem because it basically renders it useless (too unreliable).
>
> If you have problems reproducing it, try changing ｢/ 10｣ to something
> else. This delay is not really relevant but it seems like it affects the
> chances to get one result or another.
>
> Here's also a golfed down version:
>
> Code:
> dd @(^10 .hyper(:1batch).map: { sleep rand; $_ })
>
> Result:
> ()
> OR
> (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
>
> According to the execution time ｢hyper｣ does not even bother to compute the
> result in these problematic cases (it just returns an empty list without
> trying to process the data). That being said, there is a chance that it
> fails half way through, see next example.
>
>
> Another interesting issue (probably the same one):
>
> Code:
> .say for (^10).hyper(:1batch).map: { sleep rand; $_ }
>
> Result:
> 1
> OR
> 2
> OR
> 3
> OR
> 0
> 3
> 2
> 1
> 5
> 8
> 7
> 4
> 6
> 9
> OR etc.
>
> So not only it is out of order (#127099), but it is also extremely broken.
>
> It looks like there is no such problem with ｢race｣.
>
> IRC log (nothing useful there though):
> http://irclog.perlgeek.de/perl6/2016-02-02#i_11975794
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t (for original post and other examples that I found in the
discussion of this ticket).
[perl #130576] [CONC] .race & .hyper break [+] (1..100)
On Tue, 17 Jan 2017 10:10:44 -0800, coke wrote: > The presence of a hyper or race causes incorrect output in some cases. > Originally found with the .grep in the pipeline, but seems to impact > even the simple case. > > $ perl6 -e 'say [+] (1..100)' > 5050 > > $ perl6 -e 'say [+] (1..100).race' > 0 > > $ perl6 -e 'say [+] (1..100).grep(* != 22)' > 5028 > > $ perl6 -e 'say [+] (1..100).race.grep(* != 22)' > 0 > > $ perl6 -e 'say [+] (1..100).hyper.grep(* != 22)' > 0 > > $ perl6 -e 'say [+] (1..100).grep(* != 22).race' > 0 > > $ perl6 -e 'say [+] (1..100).grep(* != 22).hyper' > 0 > Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and S07-hyperrace/race.t.
[perl #126597] [CONC][BUG] .race.grep(...) and .hyper.grep(...) produce an empty sequence
On Mon, 09 Nov 2015 06:36:49 -0800, matt.oa...@congenica.com wrote:
> The following has an empty result when using race or hyper in perl6
> version 2015.10-233-gac750a9 built on MoarVM version 2015.10-61-
> g624d504
>
> $ perl6
> > (1..10).grep(* > 3)
> (4 5 6 7 8 9 10)
> > (1..10).race().grep(* > 3)
> ()
> > (1..10).hyper().grep(* > 3)
> ()
>
> Looks specifically like the methods after the hyper/race never get
> called:
>
> > (1..10).hyper().grep(* > 3).map({$_.say; $_})
> ()
> > (1..10).map({$_.say; $_}).hyper().grep(* > 3)
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> ()
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t.
[perl #126597] [CONC][BUG] .race.grep(...) and .hyper.grep(...) produce an empty sequence
On Mon, 09 Nov 2015 06:36:49 -0800, matt.oa...@congenica.com wrote:
> The following has an empty result when using race or hyper in perl6
> version 2015.10-233-gac750a9 built on MoarVM version 2015.10-61-
> g624d504
>
> $ perl6
> > (1..10).grep(* > 3)
> (4 5 6 7 8 9 10)
> > (1..10).race().grep(* > 3)
> ()
> > (1..10).hyper().grep(* > 3)
> ()
>
> Looks specifically like the methods after the hyper/race never get
> called:
>
> > (1..10).hyper().grep(* > 3).map({$_.say; $_})
> ()
> > (1..10).map({$_.say; $_}).hyper().grep(* > 3)
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> ()
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t.
[perl #130576] [CONC] .race & .hyper break [+] (1..100)
On Tue, 17 Jan 2017 10:10:44 -0800, coke wrote: > The presence of a hyper or race causes incorrect output in some cases. > Originally found with the .grep in the pipeline, but seems to impact > even the simple case. > > $ perl6 -e 'say [+] (1..100)' > 5050 > > $ perl6 -e 'say [+] (1..100).race' > 0 > > $ perl6 -e 'say [+] (1..100).grep(* != 22)' > 5028 > > $ perl6 -e 'say [+] (1..100).race.grep(* != 22)' > 0 > > $ perl6 -e 'say [+] (1..100).hyper.grep(* != 22)' > 0 > > $ perl6 -e 'say [+] (1..100).grep(* != 22).race' > 0 > > $ perl6 -e 'say [+] (1..100).grep(* != 22).hyper' > 0 > Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and S07-hyperrace/race.t.
[perl #131865] [REGRESSION] Looping over a HyperSeq in sink context does nothing (for .hyper { say 2 })
On Tue, 08 Aug 2017 18:40:48 -0700, alex.jakime...@gmail.com wrote:
> Code:
> for .hyper { say 2 }
>
> Result (2015.09-2015.06):
> 2
> 2
> 2
>
> Result (9b0b9effe5,2017.07,HEAD(6745517)):
> (no output)
>
>
> There seems to be nothing wrong with using a for loop on .hyper or
> .race, so it should work. It starts working if you somehow use the
> value, for example:
>
> Code:
> do for .hyper { say 2 }
>
> Result (9b0b9effe5,2017.07,HEAD(6745517)):
> 2
> 2
> 2
>
>
> Bisectable points to
> https://github.com/rakudo/rakudo/commit/9b0b9effe5fee1f35497cf97a5e7bda9bb083507
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t.
[perl #131865] [REGRESSION] Looping over a HyperSeq in sink context does nothing (for .hyper { say 2 })
On Tue, 08 Aug 2017 18:40:48 -0700, alex.jakime...@gmail.com wrote:
> Code:
> for .hyper { say 2 }
>
> Result (2015.09-2015.06):
> 2
> 2
> 2
>
> Result (9b0b9effe5,2017.07,HEAD(6745517)):
> (no output)
>
>
> There seems to be nothing wrong with using a for loop on .hyper or
> .race, so it should work. It starts working if you somehow use the
> value, for example:
>
> Code:
> do for .hyper { say 2 }
>
> Result (9b0b9effe5,2017.07,HEAD(6745517)):
> 2
> 2
> 2
>
>
> Bisectable points to
> https://github.com/rakudo/rakudo/commit/9b0b9effe5fee1f35497cf97a5e7bda9bb083507
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t.
[perl #128084] [CONC][BUG] `.hyper/.race.map()` produces an empty sequence if `` is a multi-sub
On Fri, 06 May 2016 08:37:20 -0700, sml...@gmail.com wrote:
> ➜ sub f ($a) { $a**2 }; say (^10).hyper.map().list;
> (0 1 4 9 16 25 36 49 64 81)
>
> ➜ multi f ($a) { $a**2 }; say (^10).hyper.map().list;
> ()
>
> The expected behavior would be for both examples to produce the same
> (non-empty) list.
>
> (This was first reported by Alexander Moquin in a comment to ticket
> #126597, but I think it should have its own ticket.)
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t.
[perl #129234] [CONC] `.hyper` and `.race` resume after exceptions
On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote:
> If you `die` inside a `map/for` that is being `hyper/race`d...
>
> for (1..1).hyper { die }; sleep 1; say "Alive";
>
> ...it prints the exception's backtrace, but then resumes the program
> as if nothing had happened:
>
> Died
> in block at -e line 1
>
> Alive
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t. The new error reporting shows the backtrace of both the
thing that went wrong in a worker thread, and the place that triggered the
iteration.
[perl #128084] [CONC][BUG] `.hyper/.race.map()` produces an empty sequence if `` is a multi-sub
On Fri, 06 May 2016 08:37:20 -0700, sml...@gmail.com wrote:
> ➜ sub f ($a) { $a**2 }; say (^10).hyper.map().list;
> (0 1 4 9 16 25 36 49 64 81)
>
> ➜ multi f ($a) { $a**2 }; say (^10).hyper.map().list;
> ()
>
> The expected behavior would be for both examples to produce the same
> (non-empty) list.
>
> (This was first reported by Alexander Moquin in a comment to ticket
> #126597, but I think it should have its own ticket.)
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t.
[perl #129234] [CONC] `.hyper` and `.race` resume after exceptions
On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote:
> If you `die` inside a `map/for` that is being `hyper/race`d...
>
> for (1..1).hyper { die }; sleep 1; say "Alive";
>
> ...it prints the exception's backtrace, but then resumes the program
> as if nothing had happened:
>
> Died
> in block at -e line 1
>
> Alive
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t. The new error reporting shows the backtrace of both the
thing that went wrong in a worker thread, and the place that triggered the
iteration.
[perl #132012] Numeric values of signals are wrong (say +SIGUSR1)
On Sat, 14 Oct 2017 08:29:50 -0700, c...@zoffix.com wrote:
> Something fishy going on with the Signals enum. If that's fixed then
> the
> regression you pointed out will be fixed as well, as the new method
> simply
> uses enum's `.value` to get the signal number:
>
> c: 79b8ab9d3f^,79b8ab9d3f,HEAD say SIGUSR1.Numeric; say
> SIGUSR1.value; say $*KERNEL.signal: SIGUSR1
> Zoffix__, ¦79b8ab9d3f^: «303010»
> ¦79b8ab9,HEAD(cc6c055): «303030»
There's also a failing spectest on Windows that expects both of these to give
same value (on and Linux, they do):
C:\rakudo>perl6 -e "$*KERNEL.signal('SIGHUP').say"
3
C:\rakudo>perl6 -e "$*KERNEL.signal(SIGHUP).say"
1
[perl #132012] Numeric values of signals are wrong (say +SIGUSR1)
On Sat, 14 Oct 2017 08:29:50 -0700, c...@zoffix.com wrote:
> Something fishy going on with the Signals enum. If that's fixed then
> the
> regression you pointed out will be fixed as well, as the new method
> simply
> uses enum's `.value` to get the signal number:
>
> c: 79b8ab9d3f^,79b8ab9d3f,HEAD say SIGUSR1.Numeric; say
> SIGUSR1.value; say $*KERNEL.signal: SIGUSR1
> Zoffix__, ¦79b8ab9d3f^: «303010»
> ¦79b8ab9,HEAD(cc6c055): «303030»
There's also a failing spectest on Windows that expects both of these to give
same value (on and Linux, they do):
C:\rakudo>perl6 -e "$*KERNEL.signal('SIGHUP').say"
3
C:\rakudo>perl6 -e "$*KERNEL.signal(SIGHUP).say"
1
Re: [perl #132316] [Double Free] Crash while running program
On 10/17/2017 09:27 PM, Timo Paulssen via RT wrote: if you can, please re-compile MoarVM passing the same options that were used before (you can find them on the first screenfuls of the Makefile inside moarvm's source folder) to Configure.pl but also include --debug=3 and --optimize=0. This is an optional step. After that, please run perl6-valgrind-m instead of perl6 or perl6-m to execute your script, that should give more helpful data. Later on, to run stuff regularly again, turn optimize back up to 3, otherwise things will be noticeably slower. @timo The program didn't crash but the system got slower until a point that I had to stop it. The end result is shown below. (There are 2 more runs below this one!) ==26702== ==26702== Process terminating with default action of signal 2 (SIGINT) ==26702== at 0x5DE090B: pthread_cond_wait@@GLIBC_2.3.2 (in /usr/lib64/libpthread-2.25.so) ==26702== by 0x51061F8: uv_cond_wait (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5061E04: shift (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x50419F3: MVM_repr_shift_o (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5091898: worker (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5019EF0: thread_initial_invoke (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x4FF84F7: MVM_interp_run (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5019F6D: start_thread (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5DDA36C: start_thread (in /usr/lib64/libpthread-2.25.so) ==26702== ==26702== HEAP SUMMARY: ==26702== in use at exit: 491,357,261 bytes in 1,627,986 blocks ==26702== total heap usage: 29,576,790 allocs, 27,948,804 frees, 17,354,627,753 bytes allocated ==26702== ==26702== LEAK SUMMARY: ==26702== definitely lost: 1,213,140 bytes in 37,380 blocks ==26702== indirectly lost: 49,224 bytes in 1,709 blocks ==26702== possibly lost: 395,844 bytes in 7,003 blocks ==26702== still reachable: 489,699,053 bytes in 1,581,894 blocks ==26702== suppressed: 0 bytes in 0 blocks ==26702== Rerun with --leak-check=full to see details of leaked memory ==26702== ==26702== For counts of detected and suppressed errors, rerun with: -v ==26702== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) A run on a smaller set of files and directories ended like this ==27745== ==27745== HEAP SUMMARY: ==27745== in use at exit: 299,554,654 bytes in 996,179 blocks ==27745== total heap usage: 3,885,468 allocs, 2,889,289 frees, 2,080,116,257 bytes allocated ==27745== ==27745== LEAK SUMMARY: ==27745== definitely lost: 632,860 bytes in 19,779 blocks ==27745== indirectly lost: 15,392 bytes in 436 blocks ==27745== possibly lost: 381,904 bytes in 6,792 blocks ==27745== still reachable: 298,524,498 bytes in 969,172 blocks ==27745== suppressed: 0 bytes in 0 blocks ==27745== Rerun with --leak-check=full to see details of leaked memory ==27745== ==27745== For counts of detected and suppressed errors, rerun with: -v ==27745== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Then I ran with the option '--leak-check=full' which ended with a much larger list of data ==27960== ==27960== HEAP SUMMARY: ==27960== in use at exit: 280,544,350 bytes in 992,192 blocks ==27960== total heap usage: 3,672,304 allocs, 2,680,112 frees, 1,929,387,061 bytes allocated ==27960== ==27960== 24 bytes in 3 blocks are possibly lost in loss record 820 of 4,825 ==27960== at 0x4C2EB6B: malloc (vg_replace_malloc.c:299) ==27960== by 0x50941CD: plan_for_cs (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x50942FB: plan_for_sf (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x50944CF: MVM_spesh_plan (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5091A13: worker (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5019EF0: thread_initial_invoke (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x4FF84F7: MVM_interp_run (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5019F6D: start_thread (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5DDA36C: start_thread (in /usr/lib64/libpthread-2.25.so) ==27960== ==27960== 81 bytes in 27 blocks are definitely lost in loss record 1,626 of 4,825 ==27960== at 0x4C2EB6B: malloc (vg_replace_malloc.c:299) ==27960== by 0x509779D: MVM_string_ascii_encode_substr (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5097BF5: MVM_string_ascii_encode (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x50BA5DD: MVM_unicode_name_to_property_value_code
Re: [perl #132316] [Double Free] Crash while running program
On 10/17/2017 09:27 PM, Timo Paulssen via RT wrote: > if you can, please re-compile MoarVM passing the same options that were > used before (you can find them on the first screenfuls of the Makefile > inside moarvm's source folder) to Configure.pl but also include > --debug=3 and --optimize=0. This is an optional step. After that, please > run perl6-valgrind-m instead of perl6 or perl6-m to execute your script, > that should give more helpful data. > > Later on, to run stuff regularly again, turn optimize back up to 3, > otherwise things will be noticeably slower. > @timo The program didn't crash but the system got slower until a point that I had to stop it. The end result is shown below. (There are 2 more runs below this one!) ==26702== ==26702== Process terminating with default action of signal 2 (SIGINT) ==26702== at 0x5DE090B: pthread_cond_wait@@GLIBC_2.3.2 (in /usr/lib64/libpthread-2.25.so) ==26702== by 0x51061F8: uv_cond_wait (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5061E04: shift (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x50419F3: MVM_repr_shift_o (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5091898: worker (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5019EF0: thread_initial_invoke (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x4FF84F7: MVM_interp_run (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5019F6D: start_thread (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==26702== by 0x5DDA36C: start_thread (in /usr/lib64/libpthread-2.25.so) ==26702== ==26702== HEAP SUMMARY: ==26702== in use at exit: 491,357,261 bytes in 1,627,986 blocks ==26702== total heap usage: 29,576,790 allocs, 27,948,804 frees, 17,354,627,753 bytes allocated ==26702== ==26702== LEAK SUMMARY: ==26702== definitely lost: 1,213,140 bytes in 37,380 blocks ==26702== indirectly lost: 49,224 bytes in 1,709 blocks ==26702== possibly lost: 395,844 bytes in 7,003 blocks ==26702== still reachable: 489,699,053 bytes in 1,581,894 blocks ==26702== suppressed: 0 bytes in 0 blocks ==26702== Rerun with --leak-check=full to see details of leaked memory ==26702== ==26702== For counts of detected and suppressed errors, rerun with: -v ==26702== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) A run on a smaller set of files and directories ended like this ==27745== ==27745== HEAP SUMMARY: ==27745== in use at exit: 299,554,654 bytes in 996,179 blocks ==27745== total heap usage: 3,885,468 allocs, 2,889,289 frees, 2,080,116,257 bytes allocated ==27745== ==27745== LEAK SUMMARY: ==27745== definitely lost: 632,860 bytes in 19,779 blocks ==27745== indirectly lost: 15,392 bytes in 436 blocks ==27745== possibly lost: 381,904 bytes in 6,792 blocks ==27745== still reachable: 298,524,498 bytes in 969,172 blocks ==27745== suppressed: 0 bytes in 0 blocks ==27745== Rerun with --leak-check=full to see details of leaked memory ==27745== ==27745== For counts of detected and suppressed errors, rerun with: -v ==27745== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Then I ran with the option '--leak-check=full' which ended with a much larger list of data ==27960== ==27960== HEAP SUMMARY: ==27960== in use at exit: 280,544,350 bytes in 992,192 blocks ==27960== total heap usage: 3,672,304 allocs, 2,680,112 frees, 1,929,387,061 bytes allocated ==27960== ==27960== 24 bytes in 3 blocks are possibly lost in loss record 820 of 4,825 ==27960== at 0x4C2EB6B: malloc (vg_replace_malloc.c:299) ==27960== by 0x50941CD: plan_for_cs (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x50942FB: plan_for_sf (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x50944CF: MVM_spesh_plan (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5091A13: worker (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5019EF0: thread_initial_invoke (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x4FF84F7: MVM_interp_run (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5019F6D: start_thread (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5DDA36C: start_thread (in /usr/lib64/libpthread-2.25.so) ==27960== ==27960== 81 bytes in 27 blocks are definitely lost in loss record 1,626 of 4,825 ==27960== at 0x4C2EB6B: malloc (vg_replace_malloc.c:299) ==27960== by 0x509779D: MVM_string_ascii_encode_substr (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x5097BF5: MVM_string_ascii_encode (in /home/marcel/Software/perl6/rakudo/install/lib/libmoar.so) ==27960== by 0x50BA5DD:
Re: [perl #132316] [Double Free] Crash while running program
@Aleks-Daniel Jakimenko-Aleksejev How can I reproduce this issue? What code did you use? Well, 1) Install a mongod server and start it up. Its address might be 127.0.0.1:27017 which is the default for mongod servers. Servers can be downloaded using $ curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-3.2.9.tgz When unpacked, you can find the server in the bin directory. 2) Install MongoDB. it depends on a host of modules. 3) Install the Library project from github; https://github.com/MARTIMM/Library 4) Setup a config file in $HOME/.library/config.toml database = "Library" uri = "mongodb://127.0.0.1:27017" [collection] meta-config = "Metaconfig" meta-data = "Metadata" 5) Run the program (take a directory which is not of value for you to be sure! like /tmp) $ store-file-metadata.pl6 fs -et -r If the directory is sufficiently large/deep, the program will crash. I can imagine that this will take too much to do, thanks anyway if you try. Marcel
Re: [perl #132316] [Double Free] Crash while running program
@Aleks-Daniel Jakimenko-Aleksejev > How can I reproduce this issue? What code did you use? > Well, 1) Install a mongod server and start it up. Its address might be 127.0.0.1:27017 which is the default for mongod servers. Servers can be downloaded using $ curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-3.2.9.tgz When unpacked, you can find the server in the bin directory. 2) Install MongoDB. it depends on a host of modules. 3) Install the Library project from github; https://github.com/MARTIMM/Library 4) Setup a config file in $HOME/.library/config.toml database = "Library" uri = "mongodb://127.0.0.1:27017" [collection] meta-config = "Metaconfig" meta-data = "Metadata" 5) Run the program (take a directory which is not of value for you to be sure! like /tmp) $ store-file-metadata.pl6 fs -et -r If the directory is sufficiently large/deep, the program will crash. I can imagine that this will take too much to do, thanks anyway if you try. Marcel
