| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I found this memory leak by evaluating lines of the Copying file as
Perl code. :-)
The parser requires yylex to return exactly one token with each call.
Sometimes yylex needs to record a few tokens ahead of time, so its
puts them in its forced token stack. The next call to yylex then pops
the pending token off that stack.
Ops belong to their subroutines. If the subroutine is freed before
its root is attached, all the ops created when PL_compcv pointed
to that sub are freed as well. To avoid crashes, the ops on the
savestack and the forced token stack are specially marked so they are
not freed when the sub is freed.
When it comes to evaluating "END OF TERMS AND CONDITIONS", the END
token causes a subroutine to be created and placed in PL_compcv. The
OF token is treated by the lexer as a method call on the TERMS pack-
age. The TERMS token is placed in the forced token stack as an sv in
an op for a WORD token, and a METHOD token for OF is returned. As
soon as the parser sees the OF, it generates an error, which results
in LEAVE_SCOPE being called, which frees the subroutine for END while
TERMS is still on the forced token stack. So the subroutine’s op
cleanup skips that op. Then the parser calls back into the lexer,
which returns the TERMS token from the forced token stack. Since
there has been an error, the parser discards that token, so the op
is never freed. The forced token stack cleanup that happens in
parser_free does not catch this, as the token is no longer on
that stack.
Earlier, to solve the problem of yylex returning freed ops to the
parser, resulting in crashes, I set the op_savefree flag on ops on the
forced token stack. But that resulted in a leak.
So now I am using a different approach: When the sub is freed and
frees all its ops, have it also look in the parser’s forced token
stack, freeing any ops that belong to it, and setting the point-
ers to null.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by "Eric Brine"
# Please include the string: [perl #115710]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=115710 >
This is a bug report for perl from ikegami@adaelis.com,
generated with the help of perlbug 1.39 running under perl 5.14.2.
-----------------------------------------------------------------
[Please describe your issue here]
Attached patch silences two build warnings on systems where ivsize >
ptrsize.
They are safe to ignore, a side-effect of a function with a polymorphic
interface.
cv = find_runcv_where(FIND_RUNCV_level_eq, iv, NULL);
cv = find_runcv_where(FIND_RUNCV_padid_eq, PTR2IV(p), NULL); // p is a
PADNAMELIST*
[Please do not change anything below this line]
-----------------------------------------------------------------
|
| |
|
|
|
|
|
|
|
| |
pad_free() clears the SVs_PADTMP bit. Since that bit is now shared
with SVs_PADSTALE, that gets cleared on state vars. It didn't matter up
till now, but the next commit will start optimising away pad ops, and
op_null() will call pad_free() which would clear the SVs_PADSTALE bit.
So only clear SVs_PADTMP/SVs_PADSTALE for non-lexical var ops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By defining NO_TAINT_SUPPORT, all the various checks that perl does for
tainting become no-ops. It's not an entirely complete change: it doesn't
attempt to remove the taint-related interpreter variables, but instead
virtually eliminates access to it.
Why, you ask? Because it appears to speed up perl's run-time
significantly by avoiding various "are we running under taint" checks
and the like.
This change is not in a state to go into blead yet. The actual way I
implemented it might raise some (valid) objections. Basically, I
replaced all uses of the global taint variables (but not PL_taint_warn!)
with an extra layer of get/set macros (TAINT_get/TAINTING_get).
Furthermore, the change is not complete:
- PL_taint_warn would likely deserve the same treatment.
- Obviously, tests fail. We have tests for -t/-T
- Right now, I added a Perl warn() on startup when -t/-T are detected
but the perl was not compiled support it. It might be argued that it
should be silently ignored! Needs some thinking.
- Code quality concerns - needs review.
- Configure support required.
- Needs thinking: How does this tie in with CPAN XS modules that use
PL_taint and friends? It's easy to backport the new macros via PPPort,
but that doesn't magically change all code out there. Might be
harmless, though, because whenever you're running under
NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false.
Thus, the only CPAN code that SHOULD be adversely affected is code
that changes taint state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added pad IDs so that a pad could record which pad it closes over,
to avoid problems with closures closing over the wrong pad, resulting
in crashes or bizarre copies. These pad IDs were shared between
clones of the same pad.
In commit 9ef8d56, for efficiency I made clones of the same closure
share the same pad name list.
It has just occurred to be that each padlist containing the same pad
name list also has the same pad ID, so we can just use the pad name
list itself as the ID.
This makes padlists 32 bits smaller and eliminates PL_pad_generation
from the interpreter struct.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
my subs are cloned on scope entry. To make closures work, a stub
stored in the pad (and closed over elsewhere) is cloned into.
But we need somewhere to store the prototype from which the clone is
made. I was attaching the prototype via magic to the stub in the pad,
since the pad is available at run time, but not the pad names.
That leads to lots of little games all over the place to make sure
the prototype isn’t lost when the pad is swiped on scope exit
(SAVEt_CLEARSV in scope.c). We also run the risk of losing it if an
XS module replaces the sub with another.
Instead, we should be storing it with the pad name. The previous com-
mit made the pad names available at run time, so we can move it there
(still stuffed inside a magic box) and delete much code.
This does mean that newMYSUB cannot rely on the behaviour of non-clon-
able subs that close over variables (or subs) immediately. Previ-
ously, we would dig through outer scopes to find the stub in cases
like this:
sub y {
my sub foo;
sub x {
sub {
sub foo { ... }
}
}
}
We would stop at x, which happens to have y’s stub in its pad, so
that’s no problem.
If we attach it to the pad name, we definitely have to dig past x to
get to the pad name in y’s pad.
Usually, immediate closures do not store the parent pad index, since
it will never be used. But now we do need to use it, so we modify the
code in pad.c:S_pad_findlex to set it always for my/state.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By using find_runcv_where both for formats and my subs nested in inner
clonable subs, we can simplify the code.
It happens to make this work ($x is visible):
use 5.01;
sub not_lexical8 {
my sub foo;
foo();
sub not_lexical9 {
my sub bar {
my $x = 'khaki car keys for the khaki car';
not_lexical8();
sub foo { warn $x }
}
bar()
}
}
not_lexical9();
This is definitely iffy code, but if making it work makes the imple-
mentation simpler, so why not?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sub foo {
my $x;
format =
@
$x||'#'
.
}
write;
__END__
Variable "$x" is not available at - line 9.
That one’s OK.
sub foo {
my sub x {};
format =
@
&x
.
}
write;
__END__
Variable "&x" is not available at - line 9.
Assertion failed: (SvTYPE(_svmagic) >= SVt_PVMG), function S_mg_findext_flags, file mg.c, line 404.
Abort trap
That should say ‘Subroutine’. And it shouldn’t crash.
The my-sub-cloning code was not taking this case into account. The
value in the proto pad is an undef scalar.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sub {
my $x;
sub { eval '$x' }
}->()()
__END__
Variable "$x" is not available at (eval 1) line 2.
That one’s OK (though I wonder about the line number).
sub {
my sub x {};
sub { eval '\&x' }
}->()()
__END__
Variable "&x" is not available at (eval 1) line 1.
That should say ‘Subroutine’.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code prints ARRAY(0x802e10), whereas it should print
SCALAR(0xfedbee):
undef &bar;
eval 'sub bar { my @x }';
{
my sub foo;
foo();
sub bar {
CORE::state $x;
sub foo { warn \$x }
}
}
The foo sub has a strong CvOUTSIDE pointer, but what it points to
can still be undefined and redefined. So we need to identify it
by its pad.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PadnameOUTER (SvFAKE) entries in pads of clonable subs contain the
offset in the parent pad where the closed-over entry is to be found.
The pad itself does not reference the outer lexical until the sub is
cloned at run time.
newMYSUB had to account for that by following CvOUTSIDE for
PadnameOUTER entries, to account for cases like this:
my sub foo;
my sub bar { sub foo {} }
The sub foo{} definition would have to find the my sub foo declaration
from outside and store the sub there.
That code was not accounting for named package subs, which close over
variables at compile time, so they don’t need (and don’t) store a par-
ent offset.
So outcv would point to bar in this case:
my sub foo;
sub bar { sub foo {} }
If outcv matched CvOUTSIDE(foo), then CvOUTSIDE was made weak.
That does not help in cases like this:
undef *bar;
{
my sub foo;
sub bar { sub foo {} }
}
If foo has a weak CvOUTSIDE pointer, then it will still point to bar
after bar is freed, which does not help when the sub is cloned and
tries to look at CvROOT(CvOUTSIDE).
If the pad name is marked PadnameOUTER, even if it has no parent pad
index, newMYSUB needs to leave the CvOUTSIDE pointer strongc.
Also, pad_fixup_inner_anons did not account for subs with strong
CvOUTSIDE pointers whose CvOUTSIDE point to the sub whose pad is being
iterated through.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this example,
{
my sub foo;
sub bar {
sub foo { }
}
}
the foo sub is cloned when the scope containing the ‘my sub’ declara-
tion is entered, but foo’s CvOUTSIDE pointer points to something other
than the active sub. cv_clone assumes that the currently-running sub
is the right sub to close over (at least for subs; formats are another
matter). That was true in the absence of my subs. This commit
changes it to account.
I had to tweak the test, which was wrong, because sub foo was closing
over a stale var.
|
| |
|
|
|
|
|
|
|
|
|
| |
The CvHASEVAL flag lets cv_clone know that the clone needs to have its
CvOUTSIDE pointer set, for the sake of string evals’ being able to
look up variables.
It was only being set on anonymous subs. It should be set for all
clonable subs. It doesn’t actually hurt to set it on all types of
subs, whether clonable or not, since it has no effect on non-clon-
able subs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had not yet fixed Perl_pad_fixup_inner_anons to account for the
fact that my sub prototype CVs are stored in magic attached to
the SV slot in the pad, rather than directly in the pad. It also
did not like & entries that close over subs defined in outer
or inner subs (‘my sub foo; sub bar; sub bar { &foo } }’ and
‘sub bar; sub bar { my sub foo; sub { sub foo { } } }’ respectively).
This was resulting in assertion failures, unsurprisingly.
Some of the tests I added, which were causing assertion failures, are
now failing for other reasons, and are marked as to-do.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pad slot for a my sub now holds a stub with a prototype CV
attached to it by proto magic.
The prototype is cloned on scope entry. The stub in the pad is used
when cloning, so any code that references the sub before scope entry
will be able to see that stub become defined, making these behave
similarly:
our $x;
BEGIN { $x = \&foo }
sub foo { }
our $x;
my sub foo { }
BEGIN { $x = \&foo }
Constants are currently not cloned, but that may cause bugs in
pad_push. I’ll have to look into that.
On scope exit, lexical CVs go through leave_scope’s SAVEt_CLEARSV sec-
tion, like lexical variables. If the sub is referenced elsewhere, it
is abandoned, and its proto magic is stolen and attached to a new stub
stored in the pad. If the sub is not referenced elsewhere, it is
undefined via cv_undef.
To clone my subs on scope entry, we create a sequence of introcv and
clonecv ops. See the huge comment in block_end that explains why we
need two separate ops for each CV.
To allow my subs to be defined in inner subs (my sub foo; sub { sub
foo {} }), pad_add_name_pvn and S_pad_findlex now upgrade the entry
for a my sub to a CV to begin with, so that fake entries added to pads
(fake entries are those that reference outer pads) can share the same
CV. Otherwise newMYSUB would have to add the CV to every pad that
closes over the ‘my sub’ declaration. newMYSUB no longer throws away
the initial value replacing it with a new one.
Prototypes are not currently visible to sub calls at compile time,
because the lexer sees the empty stub. A future commit will
solve that.
When I added name heks to CV’s I made mistakes in a few places, by not
turning on the CVf_NAMED flag, or by not clearing the field when free-
ing the hek. Those code paths were not exercised enough by state
subs, so the problems did not show up till now. So this commit fixes
those, too.
One of the tests in lexsub.t, involving foreach loops, was incorrect,
and has been fixed. Another test has been added to the end for a par-
ticular case of state subs closing over my subs that I broke when ini-
tially trying to get sibling my subs to close over each other, before
I had separate introcv and clonecv ops.
|
| |
|
|
|
|
|
|
| |
cv_clone has serendipitously gained the ability to clone CVs without
pads. It is not clear that we want to add this ability to this API
function, because we would be stuck supporting it, even if we came up
with a better interface. It used to crash or fail an assertion if
there was no pad.
|
| |
|
|
|
|
|
|
|
| |
This will be used by cv_clone_into (which does not exist yet) in a
later commit. pp_clonecv will use cv_clone_into.
Teasing out the pad-related and non-pad-related parts of cv_clone
was the easiest way to do this. Now the pad stuff is in a separate
function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since state variables are not shared between closures, but only
between invocations of the same closure, state subs should behave
the same way.
This was a little tricky. When we clone a sub, we now clone inner
state subs at the same time. When walking through the pad, cloning
items, we cannot simply clone the inner sub when we see it, because it
may close over things we haven’t cloned yet:
sub {
state sub foo;
my $x
sub foo { $x }
}
We can’t just delay cloning it and do it afterwards, because they may
be multiple subs closing over each other:
sub {
state sub foo;
state sub bar;
sub foo { \&bar }
sub bar { \&foo }
}
So *all* the entries in the new pad must be filled before any inner
subs can be cloned.
So what we do is put a stub in place of the cloned sub. And then
in a second pass clone the inner subs, reusing the stubs from the
first pass.
|
| |
|
|
|
|
| |
It should be ‘subroutine &foo’. (It could be ‘subroutine foo’, but we
use both forms elsewhere, and &foo is the easier to implement, the &
already being contained in the pad name.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a sub starts being parsed, a new CV is created. When it fin-
ishes, it is stored in its final location. If there is a stub there
already, the pad is copied to the stub and the body attached thereto.
Since there may be closures inside the sub whose CvOUTSIDE
pointers point to the temporary CV used during compilation,
pad_fixup_inner_anons is called, to reassign all those
CvOUTSIDE pointers.
This happens in cases like this:
sub f;
sub f { sub { } }
When a sub closes over a lexical item in an outer sub, the inner sub
gets its own pad entry with the same value as the outer pad entry.
This means that, now that we have lexical subs (currently just state
subs), we can end up with a pad entry (&s) holding a sub whose
CvOUTSIDE does not point to the sub (f) that owns the pad:
state sub s { }
sub f { s() }
If the f sub has to reuse a stub, then pad_fixup_inner_anons gets to
see that, and complains bitterly:
$ ./perl -Ilib -E 'state sub s; sub f; sub f { s() }'
Assertion failed: (CvOUTSIDE(innercv) == old_cv), function Perl_pad_fixup_inner_anons, file pad.c, line 2095.
Abort trap
|
| |
|
|
| |
This will allow named lexical subs to exist independent of GVs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 9ef8d56 I made closures share their pad name lists, and not just
the names themselves, for speed (no need to SvREFCNT_inc each name and
copy the list).
To make that work, I had to set PL_comppad_name in cv_clone, before
the pad_new call. But I failed to move the PL_comppad_name localisa-
tion from pad_new to cv_clone.
So cv_clone would merrily clobber the previous value of
PL_comppad_name *before* localising it.
This only manifested itself in source filters. Most of the time,
pp_anoncode is called at run time when either no code is being com-
piled (PL_comppad_name is only used at compile time) or inside a
BEGIN block which itself localises PL_comppad_name. But inside a
Filter::Util::Call source filter there was no buffer like that to
protect it.
This meant that pad name creation (my $x) would create the name in the
PL_comppad_name belonging to the last-cloned sub. A subsequent name
lookup ($x) would look in the correct place, as it uses the moral
equivalent of PadlistNAMES(CvPADLIST(PL_compcv)), not PL_comppad_name.
So it would not find it, resulting in a global variable or a stricture
violation.
|
| |
|
|
|
|
|
|
|
|
|
| |
Pad names are immutable once the sub is compiled. They are shared
between clones. Instead of creating a new array containing the same
pad name SVs, just share the whole array.
cv_undef does not need to modify the pad name list when removing an
anonymous sub, so we can just delete that code. That was the only
thing modifying them between compilation and freeing, as far as I
could tell.
|
| |
|
|
|
|
| |
This refactoring reduces the line count and makes it clear that the basic
logic is the same with or without -DPERL_DEBUG_READONLY_OPS. It make no
change to the generated assembler on a normal build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a while, I realised that it can be confusing for PAD_ARRAY and
PAD_MAX to take a pad argument, but for PAD_SV to take a number and
PAD_SET_CUR a padlist.
I was copying the HEK_KEY convention, which was probably a bad idea.
This is what we use elsewhere:
TypeMACRO
----=====
AvMAX
CopFILE
PmopSTASH
StashHANDLER
OpslabREFCNT_dec
Furthermore, heks are not part of the API, so what convention they use
is not so important.
So these:
PADNAMELIST_*
PADLIST_*
PADNAME_*
PAD_*
are now:
Padnamelist*
Padlist*
Padname*
Pad*
|
| |
|
|
|
| |
I think this is the last bit of pad-as-sv stuff that was not
abstracted away in pad-specific macros.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I know that a few times I’ve looked at perl source files to find out
what type to use in ‘<type> foo = PL_whatever’. So I am changing
intrpvar.h as well as the api docs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CVs close over their outer CVs. So, when you write:
my $x = 52;
sub foo {
sub bar {
sub baz {
$x
}
}
}
baz’s CvOUTSIDE pointer points to bar, bar’s CvOUTSIDE points to foo,
and foo’s to the main cv.
When the inner reference to $x is looked up, the CvOUTSIDE chain is
followed, and each sub’s pad is looked at to see if it has an $x.
(This happens at compile time.)
It can happen that bar is undefined and then redefined:
undef &bar;
eval 'sub bar { my $x = 34 }';
After this, baz will still refer to the main cv’s $x (52), but, if baz
had ‘eval '$x'’ instead of just $x, it would see the new bar’s $x.
(It’s not really a new bar, as its refaddr is the same, but it has a
new body.)
This particular case is harmless, and is obscure enough that we could
define it any way we want, and it could still be considered correct.
The real problem happens when CVs are cloned.
When a CV is cloned, its name pad already contains the offsets into
the parent pad where the values are to be found. If the outer CV
has been undefined and redefined, those pad offsets can be com-
pletely bogus.
Normally, a CV cannot be cloned except when its outer CV is running.
And the outer CV cannot have been undefined without also throwing
away the op that would have cloned the prototype.
But formats can be cloned when the outer CV is not running. So it
is possible for cloned formats to close over bogus entries in a new
parent pad.
In this example, \$x gives us an array ref. It shows ARRAY(0xbaff1ed)
instead of SCALAR(0xdeafbee):
sub foo {
my $x;
format =
@
($x,warn \$x)[0]
.
}
undef &foo;
eval 'sub foo { my @x; write }';
foo
__END__
And if the offset that the format’s pad closes over is beyond the end
of the parent’s new pad, we can even get a crash, as in this case:
eval
'sub foo {' .
'{my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$t,$u)}'x999
. q|
my $x;
format =
@
($x,warn \$x)[0]
.
}
|;
undef &foo;
eval 'sub foo { my @x; my $x = 34; write }';
foo();
__END__
So now, instead of using CvROOT to identify clones of
CvOUTSIDE(format), we use the padlist ID instead. Padlists don’t
actually have an ID, so we give them one. Any time a sub is cloned,
the new padlist gets the same ID as the old. The format needs to
remember what its outer sub’s padlist ID was, so we put that in the
padlist struct, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to fix a bug, I need to add new fields to padlists. But I
cannot easily do that as long as they are AVs.
So I have created a new padlist struct.
This not only allows me to extend the padlist struct with new members
as necessary, but also saves memory, as we now have a three-pointer
struct where before we had a whole SV head (3-4 pointers) + XPVAV (5
pointers).
This will unfortunately break half of CPAN, but the pad API docs
clearly say this:
NOTE: this function is experimental and may change or be
removed without notice.
This would have broken B::Debug, but a patch sent upstream has already
been integrated into blead with commit 9d2d23d981.
|
| |
|
|
|
| |
Much code relies on the fact that PADLIST is typedeffed as AV.
PADLIST should be treated as a distinct type.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most register declarations in C code (and accompanying
documentation) in the Perl core. Retained are those in the ext
directory, Configure, and those that are associated with assembly
language.
See:
http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c
which says, in part:
There is no good example of register usage when using modern compilers
(read: last 10+ years) because it almost never does any good and can do
some bad. When you use register, you are telling the compiler "I know
how to optimize my code better than you do" which is almost never the
case. One of three things can happen when you use register:
The compiler ignores it, this is most likely. In this case the only
harm is that you cannot take the address of the variable in the
code.
The compiler honors your request and as a result the code runs slower.
The compiler honors your request and the code runs faster, this is the least likely scenario.
Even if one compiler produces better code when you use register, there
is no reason to believe another will do the same. If you have some
critical code that the compiler is not optimizing well enough your best
bet is probably to use assembler for that part anyway but of course do
the appropriate profiling to verify the generated code is really a
problem first.
|
| |
|
|
|
|
|
| |
I made them leak inadvertently in 5.17.2 with commit e09ac076a1da.
This was unfortunately backported to 5.16.1 (as 3149499832) without
anybody noticing the bug.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Also note the collusion between op_const_cv() and cv_clone(), whereby the
former returns a fresh copy of the SV to the latter, which is then immediately
passed to newCONSTSUB.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See also commit cae5dbbe30.
These two lines should never produce different values:
print $x, "\n";
print eval '$x', "\n";
But they were producing different values if $x happened to have the
tale flag set. Even if my in false conditional is not supported (this
was the cause of the bug report), it should still work; and it is
not the only way to get a stale lexical in an active sub (just the
easiest way).
As long as the sub containing the eval is active, the eval should be
able to see the same variables, stale or not.
However, this does get a bit tricky in cases like this, which legiti-
mately warn (from t/lib/warnings/pad):
{
my $x = 1;
$y = \$x; # force abandonment rather than clear-in-place at scope exit
sub f2 { eval '$x' }
}
f2();
In this case the f2 sub does not explicitly close over the $x, so by
the time the eval is reached the ‘right’ $x is gone.
It is only in those cases where the sub containing the eval has
the stale variable in its own pad that we can safely ignore the
stale flag.
|
| | |
|
| |
|
|
|
|
| |
The outer sub should always be active and have a pad if it is
a sub that is being cloned. Only formats can have an inactive or
padless outside. Add assertions to that effect.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
\$x and sub { $x }->() should never produce different values. But
this used to be possible because sub cloning (which happens with
sub{...}) was written to avoid closing over variables that are not
active. Not closing over inactive variables makes sense in cases like
this (because the variable doesn’t really exist yet):
sub {
my $x;
sub foo {
$x
}
}
foo;
but the logic breaks down in cases like this (which was printing 3
only on the first print):
sub foo {
my $x;
sub bar {
$x = 3;
print $x, "\n";
sub { print $x, "\n" }->()
}
}
bar();
If bar can see a scalar named $x (even if it is questionable),
sub { $x }->() should jolly well see the same scalar as the immedi-
ately enclosing sub.
The only case where a run-time cloning of a CV should refuse to close
over the same scalar that the outer sub sees is when the outer sub is
not running. That only happens with formats:
sub f {
my $x;
format =
@
$x
.
}
write STDOUT;
As of this commit, it does only happen with formats.
The actual cases of subs refusing to close over stale variables in
active parents have changed twice since 5.10.0. See the comments in
the tests.
|
| |
|
|
|
|
|
|
|
| |
The fact that the call checker is stored in magic is an implementation
detail. cv_undef does not free magic, so the call checker lives on.
If we were to move the parameter prototype into magic internally, we
would not want undef to stop clearing it. To me, the current situa-
tion with call checkers is similar.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit eliminates the old slab allocator. It had bugs in it, in
that ops would not be cleaned up properly after syntax errors. So why
not fix it? Well, the new slab allocator *is* the old one fixed.
Now that this is gone, we don’t have to worry as much about ops leak-
ing when errors occur, because it won’t happen any more.
Recent commits eliminated the only reason to hang on to it:
PERL_DEBUG_READONLY_OPS required it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I want to eliminate the old slab allocator (PL_OP_SLAB_ALLOC),
but this useful debugging tool needs to be rewritten for the new
one first.
This is slightly better than under PL_OP_SLAB_ALLOC, in that CVs cre-
ated after the main CV starts running will get read-only ops, too. It
is when a CV finishes compiling and relinquishes ownership of the slab
that the slab is made read-only, because at that point it should not
be used again for allocation.
BEGIN blocks are exempt, as they are processed before the Slab_to_ro
call in newATTRSUB. The Slab_to_ro call must come at the very end,
after LEAVE_SCOPE, because otherwise the ops freed via the stack (the
SAVEFREEOP calls near the top of newATTRSUB) will make the slab writa-
ble again. At that point, the BEGIN block has already been run and
its slab freed. Maybe slabs belonging to BEGIN blocks can be made
read-only later.
Under PERL_DEBUG_READONLY_OPS, op slabs have two extra fields to
record the size and readonliness of each slab. (Only the first slab
in a CV’s slab chain uses the readonly flag, since it is conceptually
simpler to treat them all as one unit.) Without recording this infor-
mation manually, things become unbearably slow, the tests taking hours
and hours instead of minutes.
|
