Skip Menu |
Report information
Id: 126189
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: larry <larry [at] wall.org>
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Date: Fri, 25 Sep 2015 11:55:40 -0700
Subject: [BUG] [LEAK] loop { 0, .1 ... 1000 }
From: Larry Wall <larry [...] wall.org>
To: rakudobug [...] perl.org
Download (untitled) / with headers
text/plain 377b
Leaks memory, probably due to the implicit function being called to produce the next value.  Also leaks with an explicit function, or any other form of loop around it.  (We know the sequence is terminating even if Rats aren't exact, because the implicit form turns the match into an inequality.  In any case, one can sum the series and print it out each iteration to be sure.)
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
I did run this: $ valgrind --leak-check=full --show-leak-kinds=all /home/froggs/dev/nqp/install/bin/moar --execname="$0" --libpath="/home/froggs/dev/nqp/install/share/nqp/lib" --libpath="/home/froggs/dev/nqp/install/share/perl6/lib" --libpath="/home/froggs/dev/nqp/install/share/perl6/runtime" --full-cleanup /home/froggs/dev/nqp/install/share/perl6/runtime/perl6.moarvm -e 'my $x = 0; loop { 0, .1 ... 1000; exit if $x++ > 10; }' And the two biggets memory consumoptions are: ==8073== 5,750,160 bytes in 239,590 blocks are still reachable in loss record 2,318 of 2,319 ==8073== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8073== by 0x50396A6: MVM_malloc (alloc.h:2) ==8073== by 0x50396A6: MVM_bigint_div (bigintops.c:550) ==8073== by 0x4F95053: MVM_interp_run (interp.c:1717) ==8073== by 0x503F5CD: MVM_vm_run_file (moar.c:249) ==8073== by 0x401036: main (main.c:191) ==8073== ==8073== 122,670,080 bytes in 239,590 blocks are still reachable in loss record 2,319 of 2,319 ==8073== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8073== by 0x50497F9: mp_init_size (bn_mp_init_size.c:27) ==8073== by 0x5048345: mp_div (bn_mp_div.c:126) ==8073== by 0x50396DE: MVM_bigint_div (bigintops.c:574) ==8073== by 0x4F95053: MVM_interp_run (interp.c:1717) ==8073== by 0x503F5CD: MVM_vm_run_file (moar.c:249) ==8073== by 0x401036: main (main.c:191) Note that there are still reachable. All non-reachable areas are just a bunch of kilobytes in size.
Still present on Rakudo version 2016.12-315-gdaf7e5185 built on MoarVM version 2016.12-113-gd1da1bac. Though to avoid a warning, you now have to write it like this: loop { sink (0, .1 ... 1000) } Also, while the memory leak that remains *after* each application of `...` may be the bigger worry, I think it shouldn't even accumulate memory *during* each iteration of `...`. Compare: 1) The following program uses 39.7 M of RAM shortly after starting, and still 39.7 M one minute later: .sink for 1..* 2) Whereas the following program uses about 52.4 M shortly after starting, and then keeps steadily accumulating RAM usage for as long as you run it (about 137.1 M after one minute): .sink for 1...* (Same problem for `1, 3 ... *` or `1, *+1 ... *` etc.) Brad Gilbert on Stack Overflow <http://stackoverflow.com/a/41670048/1160124> suggested that `LIST, CODE ... END` caches the whole sequence internally, in case CODE reference it. But couldn't it simply look at the arity/count of CODE to know how many elements it needs to keep in memory?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org