Skip Menu |
 

This queue is for tickets about the Future-AsyncAwait CPAN distribution.

Report information
The Basics
Id: 126037
Status: new
Priority: 0/
Queue: Future-AsyncAwait

People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.15
Fixed in: (no value)



Subject: die after nested await causes immediate program END
Download (untitled) / with headers
text/plain 393b
The attached test case causes the entire program to enter END time (doesn't die, doesn't immediately abort; all END blocks appear to run correctly): A smaller test case without the 'outer' function does not fail (pass argument 1) A smaller test case without the 'await' in 'inner' does not fail (pass argument 2) Also attached is perl.trace output from running it in case 0. -- Paul Evans
Subject: await-nested.pl
Download await-nested.pl
text/x-perl 363b
#!/usr/bin/perl use strict; use warnings; use Future; use Future::AsyncAwait; my $N = shift @ARGV // 0; my $f; async sub inner { ( $N == 2 ) or await $f; die "Oopsie\n"; } async sub outer { await inner(); } $f = Future->new; my $fret = ( $N == 1 ) ? inner() : outer(); $f->done( "result" ); print STDERR "Failure was: ", scalar $fret->failure;
Subject: perl.trace
Download perl.trace
application/octet-stream 12.1k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 563b
On Fri Aug 10 12:35:33 2018, PEVANS wrote: Show quoted text
> The attached test case causes the entire program to enter END time > (doesn't die, doesn't immediately abort; all END blocks appear to run > correctly):
Large amounts of staring in gdb suggests that the reason for this is that the `return` statement it hits last just before END yields NULL, because the `cx->blk_u.retop` was NULL. I don't yet know if that's because it's looking at the wrong entry on the context stack, or the right entry but it's been overwritten somehow. Investigation continues -- Paul Evans
Download (untitled) / with headers
text/plain 1.5k
On Tue Aug 14 10:25:33 2018, PEVANS wrote: Show quoted text
> I don't yet know if that's because it's looking at the wrong entry on > the context stack, or the right entry but it's been overwritten > somehow. > > Investigation continues
... because the perl-level context stack still contains the entry with NULL retop (level 7 here) that call_method() put there, yet the C-level stack has already returned from Perl_call_sv *-[12] CXt_SUB(&main::outer ret=0x555555d7a210) *-[11] CXt_BLOCK *-[10] CXt_LOOP_ARY *-[9] CXt_SUB(&Future::_mark_ready ret=0x555555d8aec8) *-[8] CXt_BLOCK *-[7] CXt_SUB(&Future::fail ret=(nil)) *-[6] CXt_SUB(&main::inner ret=0x555555d7a210) *-[5] CXt_BLOCK *-[4] CXt_LOOP_ARY *-[3] CXt_SUB(&Future::_mark_ready ret=0x555555d5bc90) *-[2] CXt_BLOCK *-[1] CXt_SUB(&Future::done ret=0x555555d81f18) Breakpoint 1, MY_future_fail (my_perl=<optimized out>, failure=0x555555a991e0, f=<optimized out>) at lib/Future/AsyncAwait.xs:1027 1027 fprintf(stderr, "call_method(\"fail\") cxix=%d...\n", cxstack_ix); (gdb) bt #0 MY_future_fail (my_perl=<optimized out>, failure=0x555555a991e0, f=<optimized out>) at lib/Future/AsyncAwait.xs:1027 #1 pp_leaveasync (my_perl=<optimized out>) at lib/Future/AsyncAwait.xs:1149 #2 0x000055555565526a in Perl_runops_debug (my_perl=0x555555a96260) at dump.c:2451 #3 0x00005555555bd4db in S_run_body (oldscope=1, my_perl=0x555555a96260) at perl.c:2527 #4 perl_run (my_perl=0x555555a96260) at perl.c:2455 #5 0x0000555555583f9e in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at perlmain.c:123 -- Paul Evans


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.