Front page | perl.perl5.porters |
Postings from July 2016
On Mon Jul 11 10:53:15 2016, zefram@fysh.org wrote:
> Father Chrysostomos via RT wrote:
> >On Sun Jul 10 20:00:12 2016, hkoba@cpan.org wrote:
> >> perl -e 'open my $fh, ">", \ (my $buf = ""); my $sub = eval q|sub
> >> {die}|; $sub->()'
> >
> >Bisect:
> >commit 96d7c88819733eaaba892177a967d9e898b2b924
> > [perl #57512] Warnings for implicitly closed handles
>
> The crash is dependent on both $fh and $sub being lexical variables,
> and on them being declared in that order. What's interesting about this
> requirement is that it means that $fh gets implicitly closed when the
> pad is freed, and the crash only happens if $sub has already been freed
> at that moment. Indeed, another way to avert the crash is to stick a
> reference to $sub into another lexical variable declared before $fh,
> so it does seem to be order of freeing that matters.
>
> Is there perhaps a reference to $sub on the context stack, which
> gets followed into freed memory while processing the closure of $fh?
> No warning is actually generated, but maybe the context is examined
> while checking the warning flags?
I don’t think the context stack is related per se. It probably has to do with the current cop being freed. op.c:S_cop_free sets PL_curcop to NULL if it points to the cop being freed.
If the $sub is freed first, then the statement containing the ‘die’, which PL_curcop still points to, gets freed, and PL_curcop is set to NULL. Then $fh is freed, which tries to check the warning flags, but I don’t know why.
I have not confirmed any of this. It also does not explain why the eval is necessary.
I suspect any warning that can happen during freeing could result in a similar crash. (Are there any other such warnings?)
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=128597
Thread Previous
|
Thread Next