| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
It said exactly the opposite of what was meant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the pad API was added, the special
m|pad_check_dup|SV *name|U32 flags|const HV *ourstash
sequence was added to pad.c, but that is unnecessary as it is listed
in embed.fnc. Also it is not correct, as the name of the function is
in the return value field.
So this restore it back to the simple ‘=for apidoc pad_check_dup’.
The description of the function was in plain text like this:
Check for duplicate declarations: report any of:
* a my in the current scope with the same name;
* an our (anywhere in the pad) with the same name and the same stash
as C<ourstash>
C<is_our> indicates that the name to check is an 'our' declaration
which gets rewrapped in rendered pod. So this patch changes it to use
a verbatim block (as autodoc.pl doesn’t seem to like pod lists).
|
| |
|
|
|
|
|
|
|
|
|
| |
SVs_PADSTALE is only meaningful with SVs_PADMY, while
SVs_PADTMP is only meaningful with !SVs_PADMY,
so let them share the same flag bit.
Note that this doesn't yet free a bit in SvFLAGS, as the two
bits are also used for SVpad_STATE, SVpad_TYPED.
(This is is follow-on to 62bb6514085e5eddc42b4fdaf3713ccdb7f1da85.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit da6b625f78 triggered an unrelated bug, by rearranging things in
memory so that the conditions were right:
If @DB::args has been populated, and then the items in it have been
freed, they can end up being reused for any SV-ish things allocated
thereafter, even lexical pads.
Each CV (subroutine) has a list of pads, called the padlist, which is
the same structure as a Perl array (an AV) underneath. The padlist’s
memory management is done in pad.c, as there are other things that
have to be done when its elements (the pads themselves) are freed.
So, to prevent av.c from trying to free those elements, the padlist is
not marked REAL; i.e., it’s marked as not having its elements refer-
ence-counted, even though they are: it’s just not handled in av.c
The ‘Attempt to free unreferenced scalar’ warnings emitted by
threads::shared’s clone.t occurred when padlists and pads ended up
using freed SVs that were still in @DB::args. When a new thread was
created, the pads in @DB::args ended up getting cloned when @DB::args
was cloned; hence they were treated as non-reference-counting arrays,
and the pads inside them were cloned with a lower reference count than
they ought to have had (sv_dup was called, instead of sv_dup_inc).
The pad-duplication code (pad_dup), like the regular SV-duplication
code, checks first to see if a padlist has been cloned already, before
actually doing it. There was also a problem with pad_dup not incre-
menting the reference count of an already-cloned padlist.
So this commit fixes the pad_dup reference-counting bug and also
leaves AvREAL on for padlists, until the very last moment when they
are freed (in pad_free) with SvREFCNT_dec.
|
| |
|
|
|
|
|
|
|
|
| |
Subs in the CORE package with a (_) prototype will use this.
This accepts a CV and a sequence number, so that one can
use it to find the $_ in the caller’s scope. It only uses
the topmost call of a subroutine that is being called recur-
sively, so it’s not really a general-purpose function. But
it suffices for &CORE::abs and friends.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ perl -le' undef &{$x=sub{}}; $x->()'
Not a CODE reference at -e line 1.
undeffing an anonymous subroutine used to turn the ANON flag off,
causing it to bypass the condition apparently written for this situa-
tion in pp_entersub.
This commit stops cv_undef from turning off that flag, so now we get:
$ ./perl -le' undef &{$x=sub{}}; $x->()'
Undefined subroutine called at -e line 1.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the thread starting at:
http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/msg175161.html
Instead of assuming that only Perl subs have mallocked CvFILEs and
only under threads, resulting in various hackery to borrow parts of
the SvPVX buffer where that assumption proves wrong, we can simply
add another flag (DYNFILE) to indicate whether CvFILE is mallocked,
instead of trying to use the ISXSUB flag for two purposes.
This simplifies the code greatly, eliminating bug #96126 in the pro-
cess (which had to do with sv_dup not knowing about the hackery that
this commit removes).
I removed that comment from cv_ckproto_len about CONSTSUBs doubling up
the buffer field, as it is no longer relevant. But I still left the
code as it is, since it’s better to do an explicit length check.
|
| |
|
|
| |
This was warning in DEBUGGING builds
|
| |
|
|
| |
Change its return type to bool from I32, as it only returns truth or falsehood.
|
| |
|
|
|
|
| |
cc76b5cc1552a605 added all 3 functions to the API, but declared prototypes
with const U32 flags, whilst the definitions had that parameter non-const.
Some compilers issue warnings about this inconsistency.
|
| | |
|
| | |
|
| |
|
|
| |
both sides, which isn't required, but may be more efficient than leaving it to the comparison function.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Move several pad functions into the core API. Document the pad
functions more consistently for perlapi. Fix the interface issues
around delimitation of lexical variable names, providing _pvn, _pvs,
_pv, and _sv forms of pad_add_name and pad_findmy.
|
| |
|
|
|
| |
In Perl_find_rundefsv() and PAD_COMPNAME_FLAGS_isOUR(), replace longhand flags
test with SvPAD_OUR().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
After a large number of evals, PL_cop_seqmax (a U32) will wrap around
again to zero. Make the code handle this case by:
1) When incrementing PL_cop_seqmax, never allow its value to become
equal to PERL_PADSEQ_INTRO;
2) When testing for COP_SEQ_RANGE_LOW < seq <= COP_SEQ_RANGE_HIGH,
allow for the fact that _HIGH may be lower than _LOW.
This is a final fix for [perl #83364].
|
| |
|
|
|
|
|
| |
Some of the code in pad.c tests COP_SEQ_RANGE_HIGH for the special value 0.
By instead testing COP_SEQ_RANGE_LOW for the special value PERL_PADSEQ_INTRO
(which it turns out is functioanlly equivalent), we can eliminate one of
the special values that PL_cop_seqmax mustn't be set to.
|
| |
|
|
|
|
|
|
| |
and increase its scope to all the perl core rather than just pad.c.
The scope needs to increase because we'll need to use it in op.c shortly,
and the rename is because it's about to lose any significance as a
numerical value, and just become a magic number to be tested for equality.
|
| |
|
|
|
|
|
|
|
|
| |
[perl #83364]. PL_cop_seqmax is U32 but PAD_MAX was defined as
I32_MAX. Once PL_cop_seqmax got above 2 billion it would start to appear
spuriosuly as if PL_cop_seqmax > PAD_MAX, so the scope of lexical vars in
evals etc went awry.
Also replaces a use of ~0 with PAD_MAX, which shouldn't change anything,
but is just tidier.
|
| |
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81904]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81904 >
Signed-off-by: Abigail <abigail@abigail.be>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don’t turn off readonliness on lexicals when freeing pad entries.
The readonliness is (prior to this commit) turned off explicitly in
pad_free under ithreads. See also bug #19022, which resulted from the
same change. There is some discussion there, too, but nobody seemed to
know exactly why the readonliness needed to be turned off.
Change 4761/2aa1bed, from January of 2000, added that SvREADONLY_off.
It is supposed to make sure that pad entries that were constants will
not be constants the next time they are used.
Dave Mitchell writes:
> I think...[this]...fix is correct (just removing the SvREADONLY_off).
> The issue it was trying to fix appears to have been properly fixed
> later by 3b1c21fabed159100271bd60bac3f870f5ac16af, which is why it's
> safe to remove it.
So this commit just deletes that code.
|
| |
|
|
|
| |
Pad entry 0 is for @_, but no name is recorded for it, so the name slot is
always &PL_sv_undef.
|
| |
|
|
|
|
| |
Don't even try checking the address of the pad name AV against PL_comppad, and
don't try checking the address of pad AVs against PL_comppad_name. Neither will
ever match.
|
| |
|
|
|
| |
The 0th entry in a pad is for @_, and the name corresponding to it is NULL,
so save a check.
|
| |
|
|
|
| |
Perl_pad_undef was never in the API, and has no users (elsewhere in core,
on CPAN, or anywhere else visible to Google codesearch).
|
| |
|
|
| |
This will allow the non-API function Perl_pad_undef to be inlined into it.
|
| |
|
|
|
|
|
|
|
| |
Most subroutines never recurse, hence only need 2 entries in the padlist
array - names, and depth=1. The default for av_store() is to allocate 0..3,
and even an explicit call to av_extend() with <3 will be rounded up, so we
inline the allocation of the array here.
Running ./installman allocates 7K less with this change.
|
| |
|
|
|
|
|
|
|
| |
We've just stored padname and pad as the first two elements in padlist - so
calling av_fetch() is makework.
The code was the way it was because dd2155a49b710f23 moved the two halves from
disjoint locations into the same function adjacent to each other, but didn't
spot this subsequent optimisation.
|
| |
|
|
|
| |
It now only exists as a compatibility macro for extensions that want to
introspect it.
|
| |
|
|
|
|
| |
Now that CvSTASH requires backreference bookkeeping, stop people from
directly assigning to it (by using CvSTASH() as an lvalue), and instead
force them to use CvSTASH_set().
|
| | |
|
| |
|
|
|
|
| |
Now that CvGV can sometimes be reference counted, stop people from directly
assigning to it (by using CvGV as an lvalue), and instead force them to use
CvGV_set()
|
| |
|
|
|
|
|
|
|
|
|
| |
Rather than making CvGV refcounted if the CV is anon, decide based on
whether the GV pointed to by CvGV holds a reference back to us. Normally
these two will be equivalent, but this way is more robust if people are
doing weird things.
Also spotted an error with cv_clone not clearing the CVf_CVGV_RC flag on
the newly cloned cv. This shouldn't normally matter as it will get set
shortly anyway, but best to keep things logically correct.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each CV usually has a pointer, CvGV(cv), back to the GV that corresponds
to the CV's name (or to *foo::__ANON__ for anon CVs). This pointer wasn't
reference counted, to avoid loops. This could leave it dangling if the GV
is deleted.
We fix this by:
For named subs, adding backref magic to the GV, so that when the GV is
freed, it can trigger processing the CV's CvGV field. This processing
consists of: if it looks like the freeing of the GV is about to trigger
freeing of the CV too, set it to NULL; otherwise make it point to
*foo::__ANON__ (and set CvAONON(cv)).
For anon subs, make CvGV a strong reference, i.e. increment the refcnt of
*foo::__ANON__. This doesn't cause a loop, since in this case the
__ANON__ glob doesn't point to the CV. This also avoids dangling pointers
if someone does an explicit 'delete $foo::{__ANON__}'.
Note that there was already some partial protection for CvGV with
commit f1c32fec87699aee2eeb638f44135f21217d2127. This worked by
anonymising any corresponding CV when freeing a stash or stash entry.
This had two drawbacks. First it didn't fix CVs that were anonmous or that
weren't currently pointed to by the GV (e.g. after local *foo), and
second, it caused *all* CVs to get anonymised during cleanup, even the
ones that would have been deleted shortly afterwards anyway. This commit
effectively removes that former commit, while reusing a bit of the
actual anonymising code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each CV usually has a pointer, CvSTASH, back to the stash that it was
complied in. This pointer isn't reference counted, to avoid loops. Which
can leave it dangling if the stash is deleted.
There is already protection for the similar GvSTASH field in GVs: the
stash has an array of backrefs, xhv_backreferences, pointing to the GVs
whose GvSTASHes point to it, and which is used to zero all the GvSTASH
fields should the stash be deleted.
All this patch does is also add the CVs with CvSTASH to that stash's
backref list too.
|
| |
|
|
|
|
| |
This is achieved by introducing a new find_rundefsv() function in pad.c
This fixes [perl #75436].
|
| |
|
|
|
|
|
|
|
|
| |
As newAV() and newHV() are now merely wrappers around sv_upgrade(), and the
existing SV is always brand new and of type SVt_NULL, call them on it, rather
than disposing of it as a side effect of storing a(nother new) SV.
Also, no need to set SvPADMY() again, as it is already set.
Resolves RT #73092.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, @_ was allocated for every subroutine at compile time, with a
default sized AV, hence space for 4 entries. We don't actually need to
allocate the space for entries, as there is already a check at call time as to
whether @_ is long enough.
valgrind suggests that this saves allocating 23K (on a 64 bit platform) when
running pod2man on perlfunc.pod. As well as the absolute saving, there is also
benefit in deferring allocation for subroutines actually called - for a program
which forks, @_ is less likely to be in pages shared COW with the parent.
Resolves RT #72416.
|
| |
|
|
|
|
|
|
|
| |
The PADSTALEness of lexicals between the 0th and 1st call to a subroutine is now
consistent with the state between the nth and (n + 1)th call.
This permits a work around in Perl_padlist_dup() to avoid leaking active pad
data into a new thread, whilst still correctly bodging the external references
needed by the current ?{} implementation. Fix that, and this can be removed.
|
| |
|
|
|
|
|
|
| |
This stops the values of lexicals in active stack frames in the parent leaking
into the lexicals in the child thread.
With an exception for lexicals with a reference count of > 1, to cope with the
implementation of ?{{ ... }} blocks in regexps. :-(
|
| | |
|
| |
|
|
|
| |
CvDEPTH() is 0 in a new thread, so duplicating pads beyond the always-present
first level is a waste of effort and memory.
|
| |
|
|
| |
assert() that pads are never AvREAL().
|
| | |
|
| | |
|
| | |
|
