New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
when start()ing several times in a loop #5714
Comments
From @MasterDuke17await (for ^7 { start �/etc/hostname�.IO ~~ :e }) regular perl6-valgrind-m output here: with --leak-check=full and --trace-children=yes here: |
From @nwc10On Sat, Oct 01, 2016 at 08:14:16AM -0700, Daniel Green wrote:
Nice catch. ASAN has fun: $ ./perl6-m -Ilib -e 'await (for ^7 { start �/etc/hostname�.IO ~~ :e })'==9674==ERROR: AddressSanitizer: attempting double-free on 0x603000381040 in thread T4: 0x603000381040 is located 0 bytes inside of 24-byte region [0x603000381040,0x603000381058) previously allocated by thread T0 here: Thread T4 created by T0 here: Thread T1 created by T0 here: SUMMARY: AddressSanitizer: double-free ../../.././libsanitizer/asan/asan_malloc_linux.cc:62 __interceptor_free Nicholas Clark |
The RT System itself - Status changed from 'new' to 'open' |
From @AlexDanielSurprisingly, this snippet is also buggy (but not segfaulty): await (for ^7 { start say ‘/etc/hostname’.IO }) Note that we are not doing any actual file checks here, just creating an .IO object. Running that program in an infinite loop (just wrap it in while :; do perl6 -e '…'; done ) will give you something like this: "/etc/hostname".IO "/etc/hostname".IO Oops, Null! |
From @MasterDuke17On Sun Oct 02 09:59:20 2016, alex.jakimenko@gmail.com wrote:
The valgrind output looks similar:This is Rakudo Perl 6 running in valgrind, a tool for debugging and profiling programs. ==14799== Memcheck, a memory error detector |
From @MasterDuke17On Sun Oct 02 13:57:34 2016, ddgreen@gmail.com wrote:
It's not just IO. perl6-valgrind-m -e 'await (for ^7 { start { my $a = rand; say $a} })'This is Rakudo Perl 6 running in valgrind, a tool for debugging and profiling programs. ==9911== Memcheck, a memory error detector |
From @MasterDuke17On Sun Oct 02 17:20:42 2016, ddgreen@gmail.com wrote:
If I loop this with valgrind, no errors: "my $a = rand; await (for ^7 { start { say $a } }); exit" But if I leave off that exit, every single run says (after it prints the number 7 times): |
From @jnthnSo, an update on this one. The first set of ASAN barf (involving rope flattening) and SEGVs were fixed last month by 5224878b2869. Now it can run for 10,000 iterations without trouble. Well, until it can't. Seems that the Cannot Invoke thingy happens about 1 time in a few hundred thousand iterations: jnthn@lviv:~/dev/rakudo$ seq 20 | xargs -Iz ./perl6-m -e 'await (for ^10000 { start �/etc/hostname�.IO ~~ :e })' jnthn@lviv:~/dev/rakudo$ seq 20 | xargs -Iz ./perl6-m -e 'await (for ^10000 { start �/etc/hostname�.IO ~~ :e })' jnthn@lviv:~/dev/rakudo$ seq 20 | xargs -Iz ./perl6-m -e 'await (for ^10000 { start �/etc/hostname�.IO ~~ :e })' jnthn@lviv:~/dev/rakudo$ seq 20 | xargs -Iz ./perl6-m -e 'await (for ^10000 { start �/etc/hostname�.IO ~~ :e })' Fun debugging awaits... Finally, the last set of ASAN barfage is about global destruction (as mentioned in the stack trace). This does want looking in to, but only happens when we pass the --full-cleanup flag. Thus, it's not related to the original problem, and won't happen when not running under valgrind (since we just leave cleanup to the OS in that case, which can no doubt do it far faster than we can). So, to resolve this issue we should: 1) Hunt down the cause of the rare invoke thing. /jnthn |
From @MasterDuke17On Wed, 02 Nov 2016 07:53:04 -0700, jnthn@jnthn.net wrote:
dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -v dogbert@dogbert-VirtualBox [11:02] <dogbert17> it has to do with your bug RT #129781 |
From @jnthnOn Sat, 01 Oct 2016 11:42:20 -0700, nicholas wrote:
The need for string flattening is now gone, meaning the code path that caused this bug is also, happily, gone. In S17-promie/start.t I've added a test case that far more reliably provoked the bug (in fact, I've never seen it fail to provoke the bug). About other notes on this ticket: * The "Could not invoke" issue that could also sometimes be triggered by the same code was fixed last week in MoarVM commit b4cd2a6555 (and is test covered) * The abort reported at exit is a `--full-cleanup` issue and unrelated to the original issue, so doesn't block closing this ticket. Also, since we only use --full-cleanup when running under valgrind, ordinary users will never see this. Thanks, /jnthn |
@jnthn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#129781 (status was 'resolved')
Searchable as RT129781$
The text was updated successfully, but these errors were encountered: