This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
[perl #109718] Clone PL_comppad properly
authorFather Chrysostomos <sprout@cpan.org>
Tue, 10 Apr 2012 03:11:47 +0000 (20:11 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Tue, 10 Apr 2012 21:52:59 +0000 (14:52 -0700)
commit253649d90a449f693eda6b1f50f33c291d5ae594
treeeb8fb13ae10105cf142777b54d42bae8ca55d71f
parent35c5736572cfe7a326c2bcdd39a98c514d54d038
[perl #109718] Clone PL_comppad properly

fork emulation on Windows, which clones a new thread via
perl_clone_using, expects to be able to access the current pad imme-
diately after the cloning, and crashes if there is no current pad.

PL_comppad was not being cloned explicitly, but simply looked up in
the pointer table, it being assumed that it had already been cloned.

For string evals, before commit 676a678, PL_compcv happened to point
to the eval’s CV.  PL_compcv is cloned just before PL_comppad is set,
so that worked.

As of commit 676a678, PL_compcv does not point to the eval’s CV
at the eval’s run time, so the pad has not been cloned yet when
PL_comppad is set.

In the case of string evals, the CV does get cloned, but later on,
after PL_comppad is set, when the stacks are cloned.

Changing the setting of PL_comppad to do an actual cloning works, as,
when the eval’s CV is cloned later (during stack cloning), it will
simply pick up the pad that has already been cloned and is waiting for
it in the pointer table.

This stops eval 'fork' from crashing on Windows.
pad.h