Skip Menu |
 

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

Report information
The Basics
Id: 128619
Status: resolved
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.21
Fixed in: 0.23



X-RT-Interface: Web
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 807
Download (untitled) / with headers
text/plain 807b
Hard to isolate a test case at the moment, but: foreach my $ack ( (1) x ($length-1), (0) ) { print STDERR " I2C readbyte ack=$ack\n"; $self->pirate->write( "\x04" ); await $self->pirate->read( 1, "I2C read data" )->then( sub { $ret .= $_[0]; $self->pirate->write_expect_ack( $ack ? "\x06" : "\x07", "I2C read send ACK" ); }); } Fails to run the very final (0) case, whereas my @acks = ( (1)x($length-1), (0) ); foreach my $ack ( @acks ) { print STDERR " I2C readbyte ack=$ack\n"; $self->pirate->write( "\x04" ); await $self->pirate->read( 1, "I2C read data" )->then( sub { $ret .= $_[0]; $self->pirate->write_expect_ack( $ack ? "\x06" : "\x07", "I2C read send ACK" ); }); } works fine. -- Paul Evans
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-25698-1555348611-1713.128619-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1312
Download (untitled) / with headers
text/plain 1.2k
Another case turns up in Device-AVR-UPDI: This fails: foreach my $byte ( split //, $data ) { printf STDERR "Byte is %v02X (%s)\n", $byte, $byte; $fh->print( $byte ); $buf = ""; $buf .= await Future::IO->sysread( $fh, 2 - length $buf ) while length $buf < 2; substr( $buf, 1, 1 ) eq "\x40" or croak "Expected ACK to STR data"; } But this works: my @bytes = split //, $data; # Placate RT128619 foreach my $byte ( @bytes ) { printf STDERR "Byte is %v02X (%s)\n", $byte, $byte; $fh->print( $byte ); $buf = ""; $buf .= await Future::IO->sysread( $fh, 2 - length $buf ) while length $buf < 2; substr( $buf, 1, 1 ) eq "\x40" or croak "Expected ACK to STR data"; } What's interesting in the failure case is that the value doesn't just go missing, but seems to be replaced by an entirely different value - a CODEref: Byte is 19 () Byte is 43.4F.44.45.28.30.78.35.35.62.63.35.33.64.34.33.64.61.38.29 (CODE(0x55bc53d43da8)) Future::AsyncAwait panic: TODO: Unsure how to handle savestack entry of 10 Aborted This one isn't a silent failure, it complains with an abort. Quite different from the previous test case. I suspect this might be a stack-refcount issue, where the iteration-list temporaries get stomped on by other code.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-25698-1555348611-1713.128619-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org> <rt-4.0.18-25698-1555348611-1713.128619-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-15619-1555362702-1723.128619-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 3311
Download (untitled) / with headers
text/plain 3.2k
On Mon Apr 15 13:16:51 2019, PEVANS wrote: Show quoted text
> I suspect this might be a stack-refcount issue, where the iteration- > list temporaries get stomped on by other code.
By adding some more debug printing into the suspend/resume logic around CXt_LOOP_LIST, we can observe that when this suspends, we have our values on the stack as expected: F:AA: suspend LOOP_LIST basesp=0 ix=1 SP=16 item=0x55dfc6f62638:SV{type=PV,refcnt=2,PVX=""} item=0x55dfc6f6a7d8:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6bf0b88:SV{type=PV,refcnt=1,PVX="3"} item=0x55dfc6f6af40:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f62620:SV{type=PV,refcnt=1,PVX="2"} item=0x55dfc6f6aac0:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f6a940:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6bf06c0:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f92260:SV{type=PV,refcnt=1,PVX="n"} item=0x55dfc6d6b8a0:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f6abf8:SV{type=PV,refcnt=1,PVX="/"} item=0x55dfc6f62518:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f92140:SV{type=PV,refcnt=1,PVX="+"} item=0x55dfc6d6b9d8:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f920f8:SV{type=PV,refcnt=1,PVX="-"} item=0x55dfc6ee8db8:SV{type=PV,refcnt=1,PVX="�"} F:AA suspend STACK len=16 item=0x55dfc6f62638:SV{type=PV,refcnt=2,PVX=""} item=0x55dfc6f6a7d8:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6bf0b88:SV{type=PV,refcnt=1,PVX="3"} item=0x55dfc6f6af40:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f62620:SV{type=PV,refcnt=1,PVX="2"} item=0x55dfc6f6aac0:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f6a940:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6bf06c0:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f92260:SV{type=PV,refcnt=1,PVX="n"} item=0x55dfc6d6b8a0:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f6abf8:SV{type=PV,refcnt=1,PVX="/"} item=0x55dfc6f62518:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f92140:SV{type=PV,refcnt=1,PVX="+"} item=0x55dfc6d6b9d8:SV{type=PV,refcnt=1,PVX="�"} item=0x55dfc6f920f8:SV{type=PV,refcnt=1,PVX="-"} item=0x55dfc6ee8db8:SV{type=PV,refcnt=1,PVX="�"} F:AA suspend MORTALS len=2 item=0x55dfc6f62698:SV{type=IV,refcnt=1,IV=2} item=0x55dfc6f6af70:SV{type=RV,refcnt=1,ROK} But yet, when we resume again later while we put them same SV addresses back in place, they don't appear to contain the right values any more: F:AA: resume LOOP_LIST basesp=0 ix=1 SP=16 item=0x55dfc6f62638:SV{type=PV,refcnt=1,PVX=""} item=0x55dfc6f6a7d8:SV{type=(255),refcnt=0} item=0x55dfc6bf0b88:SV{type=(255),refcnt=0} item=0x55dfc6f6af40:SV{type=(255),refcnt=0} item=0x55dfc6f62620:SV{type=(255),refcnt=0} item=0x55dfc6f6aac0:SV{type=(255),refcnt=0} item=0x55dfc6f6a940:SV{type=(255),refcnt=0} item=0x55dfc6bf06c0:SV{type=(255),refcnt=0} item=0x55dfc6f92260:SV{type=(255),refcnt=0} item=0x55dfc6d6b8a0:SV{type=(255),refcnt=0} item=0x55dfc6f6abf8:SV{type=(255),refcnt=0} item=0x55dfc6f62518:SV{type=(255),refcnt=0} item=0x55dfc6f92140:SV{type=(255),refcnt=0} item=0x55dfc6d6b9d8:SV{type=(255),refcnt=0} item=0x55dfc6f920f8:SV{type=(255),refcnt=0} item=0x55dfc6ee8db8:SV{type=(255),refcnt=0} Use of freed value in iteration at /home/leo/src/perl/Device-AVR-UPDI/blib/lib/Device/AVR/UPDI.pm line 209, <$fh> line 155. Something has cleared them out inbetween time. -- Paul Evans
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-16335-1555373248-1531.128619-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 397
Download (untitled) / with headers
text/plain 397b
Turns out to have been a mortals-handling issue. The code up to 0.22 has been erroneously looking at far too small a chunk of the mortals stack, so it didn't save anywhere nearly enough. Much rework of mortals handling puts it back into per-frame handling with the rest of the code. Patch is quite long and entangled with other changes, but soon-to-be-uploaded 0.23 will fix it. -- Paul Evans
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16907-1551063359-1059.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-32286-1555407773-1226.128619-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 34
Now fixed by 0.23 -- 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.