Skip Menu |

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

Report information
The Basics
Id: 133570
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: (no value)
Fixed in: (no value)



Subject: Memory cycle (possible leak) with die in async sub
Test case: $ cat memleak.pl #!/usr/bin/perl use strict; use warnings; use Future; use Future::AsyncAwait; use Devel::MAT::Dumper; async sub func { await Future->new; } eval { my $f = func(); Devel::MAT::Dumper::dump( "d1.pmat" ); die "Oopsie\n"; }; Devel::MAT::Dumper::dump( "d2.pmat" ); print STDERR "EOF\n"; $ perl memleak.pl EOF $ pmat d2.pmat pmat: find blessed Future HASH(3)=Future at 0x5618574c72d8: Future pmat: identify 0x5618574c72d8 HASH(3)=Future at 0x5618574c72d8 is: └─(via RV) a suspended mortal of CODE(PP) at 0x5618574c72c0, which is: └─(via RV) element [1] of ARRAY(2) at 0x5618574d1130, which is: └─(via RV) element [0] of ARRAY(1) at 0x5618574a4680, which is: └─(via RV) value {callbacks} of HASH(3)=Future at 0x5618574c72d8, which is: └─already found circularly circularly Future is being kept alive purely by a suspended mortal from its own tmpstack -- Paul Evans
Actually, this has nothing to do with the `die` part of the code. A much smaller example shows the same problem: async sub f { await Future->new } f(); -- Paul Evans