develooper Front page | perl.perl5.porters | Postings from July 2016

[perl #128708] recommended 'my sub' example in perlsub leaks memory

Father Chrysostomos via RT
July 27, 2016 05:59
[perl #128708] recommended 'my sub' example in perlsub leaks memory
Message ID:
On Sat Jul 23 15:11:40 2016, mauke- wrote:
> This is a bug report for perl from,
> generated with the help of perlbug 1.40 running under perl 5.24.0.
> -----------------------------------------------------------------
> [Please describe your issue here]
> perldoc perlsub:
> | To use a lexical subroutine from inside the subroutine itself, you
> must
> | predeclare it. The "sub foo {...}" subroutine definition syntax
> respects
> | any previous "my sub;" or "state sub;" declaration.
> |
> |     my sub baz;         # predeclaration
> |     sub baz {           # define the "my" sub
> |         baz();          # recursive call
> |     }
> This example leaks memory, just like
> my $baz;
> $baz = sub { $baz->(); };
> ($baz keeps the sub alive, the sub keeps $baz alive).
> It would be really good if recursive lexical subs could be made to not
> leak
> memory.

It cannot be fixed in general, because if you have two subs referencing each other in their pads--

    my sub foo;
    my sub bar;
    sub foo { bar if $whatever }
    sub bar { foo if $whatever }

--then you cannot know which pointer to weaken, since you cannot tell which sub will be referenced by user code last.

It might be possible to add a special case to break the reference loop of a self-referential sub.  But there is no standard for storing a weak pointer in a pad (except the format hack).  It’s not clear where to store the flag marking the pointer as weak.

Now, there is a hack for storing weak pointers to formats in pads (which are stored there solely for the sake of fixing up CvOUTSIDE pointers if they are defined within predeclared subs) consists of storing a weak RV which points to the format.

If we apply that to lexical subs, then padcv will have to have an extra special case to check for an RV.  Is it worth the added complexity for something that is only a partial fix?  If we need to educate users anyway, do we need a special case?

> Alternatively, this example should be removed from the documentation

Or replaced with a state sub example.  state subs will also leak, but no more than


> and
> replaced by a warning that doing this kind of thing leads to memory
> leaks.

Good idea.


Father Chrysostomos

via perlbug:  queue: perl5 status: new Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About