summaryrefslogtreecommitdiff
path: root/scope.c
Commit message (Collapse)AuthorAgeFilesLines
* op.c:leave_scope: use mg_free before sv_force_normalFather Chrysostomos2013-09-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is part of ticket #119295. Commit 7fa949d (5.19.3) allowed copy-on-write with compile-time con- stants. That caused this to fail: use Variable::OnDestruct: { my $h = "foo"; on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" }; $x++; # prev statement must not be last in the block } It prints undef instead of foo. It turns out this is much older: use Variable::OnDestruct; { my $h = __PACKAGE__; on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" }; $x++; # prev statement must not be last in the block } This one prints undef starting with 5.17.3 (a6d7a4ac1). But even before that, this prints undef: use Variable::OnDestruct; { my $h = \1; on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" }; $x++; # prev statement must not be last in the block } In all these cases, the scalar is getting undefined before free magic triggers (Variable::OnDestruct uses free magic). Usually when a scalar is freed, the magic is triggered before anything else. When a lexical scalar is ‘freed’ on scope exit (cleared for reuse on scope entry), the order is different. References, globs and copy-on-write scalars become undefined (via sv_force_normal) before magic is triggered. There is no reason for the order to be different here, and it causes unpredictable behaviour (you never know when you will or will not have a cow). So change the order in scope exit to match regular freeing.
* Use SSize_t for arraysFather Chrysostomos2013-08-251-8/+16
| | | | | | | | | | Make the array interface 64-bit safe by using SSize_t instead of I32 for array indices. This is based on a patch by Chip Salzenberg. This completes what the previous commit began when it changed av_extend.
* Use SSize_t when extending the stackFather Chrysostomos2013-08-251-1/+1
| | | | | | | | | | | | | | | | (I am referring to what is usually known simply as The Stack.) This partially fixes #119161. By casting the argument to int, we can end up truncating/wrapping it on 64-bit systems, so EXTEND(SP, 2147483648) translates into EXTEND(SP, -1), which does not extend the stack at all. Then writing to the stack in code like ()=1..1000000000000 goes past the end of allocated memory and crashes. I can’t really write a test for this, since instead of crashing it will use more memory than I have available (and then I’ll start for- getting things).
* Use SSize_t for tmps stack offsetsFather Chrysostomos2013-08-251-2/+19
| | | | | | | | | | | | | | | This is a partial fix for #119161. On 64-bit platforms, I32 is too small to hold offsets into a stack that can grow larger than I32_MAX. What happens is the offsets can wrap so we end up referencing and modifying elements with negative indices, corrupting memory, and causing crashes. With this commit, ()=1..1000000000000 stops crashing immediately. Instead, it gobbles up all your memory first, and then, if your com- puter still survives, crashes. The second crash happesn bcause of a similar bug with the argument stack, which the next commit will take care of.
* Revert "[perl #117855] Store CopFILEGV in a pad under ithreads"Father Chrysostomos2013-08-091-5/+0
| | | | | | | | | | | | This reverts commit c82ecf346. It turn out to be faulty, because a location shared betweens threads (the cop) was holding a reference count on a pad entry in a particu- lar thread. So when you free the cop, how do you know where to do SvREFCNT_dec? In reverting c82ecf346, this commit still preserves the bug fix from 1311cfc0a7b, but shifts it around.
* Remove SAVEt_STACK_CXPOSFather Chrysostomos2013-08-051-3/+0
| | | | 81ed78b25c4b removed the only use of this.
* [perl #117855] Store CopFILEGV in a pad under ithreadsFather Chrysostomos2013-08-051-0/+5
| | | | | | | | | | | | | | | | This saves having to allocate a separate string buffer for every cop (control op; every statement has one). Under non-threaded builds, every cop has a pointer to the GV for that source file, namely *{"_<filename"}. Under threaded builds, the name of the GV used to be stored instead. Now we store an offset into the per-interpreter PL_filegvpad, which points to the GV. This makes no significant speed difference, but it reduces mem- ory usage.
* In-place sort should not leave array read-onlyFather Chrysostomos2013-06-261-0/+3
| | | | | | | | | $ ./perl -Ilib -e '@a=1..2; eval { @a=sort{die} @a }; warn "ok so far\n"; @a = 1' ok so far Modification of a read-only value attempted at -e line 1. If something goes wrong inside the sort block and it dies, we still need to make sure we turn off the read-only flag on that array.
* eliminate PL_reg_stateDavid Mitchell2013-06-021-11/+0
| | | | | | | | | | This is a struct that holds all the global state of the current regex match. The previous set of commits have gradually removed all the fields of this struct (by making things local rather than global state). Since the struct is now empty, the PL_reg_state var can be removed, along with the SAVEt_RE_STATE save type which was used to save and restore those fields on recursive re-entry to the regex engine.
* eliminate PL_reg_poscache, PL_reg_poscache_sizeDavid Mitchell2013-06-021-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Eliminate these two global vars (well, fields in the global PL_reg_state), that hold the regex super-liner cache. PL_reg_poscache_size gets replaced with a field in the local regmatch_info struct, while PL_reg_poscache (which needs freeing at end of pattern execution or on croak()), goes in the regmatch_info_aux struct. Note that this includes a slight change in behaviour. Each regex execution now has its own private poscache pointer, initially null. If the super-linear behaviour is detected, the cache is malloced, used for the duration of the pattern match, then freed. The former behaviour allocated a global poscache on first use, which was retained between regex executions. Since the poscache could between 0.25 and 2x the size of the string being matched, that could potentially be a big buffer lying around unused. So we save memory at the expense of a new malloc/free for every regex that triggers super-linear behaviour. The old behaviour saved the old pointer on reentrancy, then restored the old one (and possibly freed the new buffer) at exit. Except it didn't for (?{}), so /(?{ m{something-that-triggers-super-linear-cache} })/ would leak each time the inner regex was called. This is now fixed automatically.
* Remove PERL_ASYNC_CHECK() from Perl_leave_scope().Nicholas Clark2013-05-091-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PERL_ASYNC_CHECK() was added to Perl_leave_scope() as part of commit f410a2119920dd04, which moved signal dispatch from the runloop to control flow ops, to mitigate nearly all of the speed cost of safe signals. The assumption was that scope exit was a safe place to dispatch signals. However, this is not true, as parts of the regex engine call leave_scope(), the regex engine stores some state in per-interpreter variables, and code called within signal handlers can change these values. Hence remove the call to PERL_ASYNC_CHECK() from Perl_leave_scope(), and add it explicitly in the various OPs which were relying on their call to leave_scope() to dispatch any pending signals. Also add a PERL_ASYNC_CHECK() to the exit of the runloop, which ensures signals still dispatch from S_sortcv() and S_sortcv_stacked(), as well as addressing one of the concerns in the commit message of f410a2119920dd04: Subtle bugs might remain - there might be constructions that enter the runloop (where signals used to be dispatched) but don't contain any PERL_ASYNC_CHECK() calls themselves. Finally, move the PERL_ASYNC_CHECK(); added by that commit to pp_goto to the end of the function, to be consistent with the positioning of all other PERL_ASYNC_CHECK() calls - at the beginning or end of OP functions, hence just before the return to or just after the call from the runloop, and hence effectively at the same point as the previous location of PERL_ASYNC_CHECK() in the runloop.
* silence warnings under NO_TAINT_SUPPORTDavid Mitchell2013-05-091-1/+3
| | | | | The are lots of places where local vars aren't used when compiled with NO_TAINT_SUPPORT.
* Fix some ASAN-identified problemsGeorge Greer2013-03-121-2/+2
| | | | | | | Clang under Address sanitizer is showing several problems when building Perl, having to do when a limit reaches I32_MAX. This commit fixes those problems by doing special tests for I32_MAX, and preventing overflow.
* scope.c: silence some compiler warningsDavid Mitchell2012-12-061-2/+3
| | | | clang didn't like %ld on I32's.
* add SvREFCNT_dec_NN()David Mitchell2012-12-041-6/+6
| | | | | | | | | Like SvREFCNT_dec(), but skips the not null check, making code potentially smaller and faster. Also as proof of concept, updates the SvREFCNT_dec's in scope.c where it's obvious the value can't be NULL. There are still 500+ uses in the perl core that need evaluating!
* Optimise magic handling in save* and leave_scopeDavid Mitchell2012-12-041-19/+25
| | | | | | | | | | | | | | | There are several places that have code similar to if (SvMAGICAL(sv)) { PL_localizing = 2; SvSETMAGIC(sv) PL_localizing = 0; } The condition is sub-optimal (it should only test for set magic), and the SvSETMAGIC repeats a similar test. Other places didn't have the outer condition, so they set PL_localizing twice even when not needed.
* refactor Perl_leave_scopeDavid Mitchell2012-12-041-204/+196
| | | | | | | | | | | | | | | | | | | This is a large and hot function. The main problem with it is that there is code to pop a few args repeated in just about every branch. Also, there are a whole bunch of local vars (sv, av, hv, gv etc) that are never all used simultaneously, but are really just there for casting convenience. Together, they defeat the compiler's register allocation algorithms (well, they did for gcc anyway). We fix this by just declaring three general vars, arg0,1,2 of type ANY, and move the popping code to above the switch(). We sort the SAVEt_* indices in order of number of args, so it's quick to determine how many args we need to pop for a particular type. Together with the previous commits which added the SS_ADD_* macros, this reduces the size of scope.o (-O2, gcc x86_64) by about 9% (threaded) or 17% (unthreaded), and seems to speed up simple loops / function calls by around 5%.
* save_int/i32 inline the long versionDavid Mitchell2012-12-041-16/+24
| | | | | | | | | | | | | Both these functions were structured as if (int will fit in type) SS_ADD(...); else save_pushi32ptr(...) Inline the call of the "long" version of the save. With refactoring, the machine code (x86_64, gcc -O2) is no larger than before, and saves time on the long version.
* Add SS_ADD_* macros and replace most SSPUSH* usesDavid Mitchell2012-12-041-57/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current idiom for adding an entry to the savestack is SSCHECK(3); SSPUSHINT(...); SSPUSHPTR(...); SSPUSHUV(SAVEt_...); Replace this with a new idiom: { dSS_ADD; SS_ADD_INT(...); SS_ADD_PTR(...); SS_ADD_UV(SAVEt_...); SS_ADD_END(3); } This is designed to be more efficient. First, it defines some local vars, and defers updating PL_savestack_ix to the end. Second, it performs the 'is there space on the stack' check *after* pushing. Doing the check last means that values in registers will have been pushed and no longer needed, so don't need saving around the call to grow. Also, tail-call elimination of the grow() can be done. These changes reduce the code of something like save_pushptrptr() to half its former size. Of course, doing the size check *after* pushing means we must always ensure there are SS_MAXPUSH free slots on the savestack */
* Clear method caches when unwinding local *foo=sub{}Father Chrysostomos2012-11-291-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | local *foo=sub{} is done in two stages: • First the local *foo localises the GP (the glob pointer, or list of slots), setting a flag on the GV. • Then scalar assignment sees the flag on the GV on the LHS and loca- lises a single slot. The slot localisation only stores on the savestack a pointer into the GP struct and the old value. There is no reference to the GV. To restore a method properly, we have to have a reference to the GV when the slot localisation is undone. So in this commit I have added a new save type, SAVEt_GVSLOT. It is like SAVEt_GENERIC_SV, except it pushes the GV as well. Currently it is used only for CVs, but I will need it for HVs and maybe AVs as well. It is possible for the unwinding of the slot localisation to affect only a GV other than the one that is pushed, if glob assignments have taken place since the local *foo. So we have to check whether the pointer is inside the GP and use PL_sub_generation++ if it is not.
* Clear method caches when unwinding local *foo=*methodFather Chrysostomos2012-11-291-4/+8
| | | | | | | | | | | | | | | | It was already working for those cases where *foo contained a sub before and after localisation. For those cases where *foo had no sub but localised assignment gave it one, method caches were not being reset on scope exit. case SAVEt_GP in scope.c:leave_scope needs to look at both GPs (glob pointer, or list of glob slots), both from before and after the unlo- calisation. If either has a sub, method caches need to be cleared. This does not yet fix local *foo = sub {}, but I added a to-do test for it. (This is more complicated, as localisation happens in two seperate steps, the glob slot localisation storing no pointers to the glob itself on the savestack.)
* Fix two local *ISA bugsFather Chrysostomos2012-11-291-5/+16
| | | | | | | | | | These are regressions from 5.8. local *ISA was not updating isa caches. local *ISA = [] was updating caches, but scope unwinding was not. Both save_gp and leave_scope/SAVEt_GP need to check whether the glob is named ISA and call mro_isa_changed_in if appropriate.
* Don’t croak for local *DetachedStash::methodFather Chrysostomos2012-11-291-1/+2
| | | | | | | save_gp was trying to call mro_method_changed_in even if the stash had been detached. This is a regression from 5.12.
* Reset method caches when GPs are sharedFather Chrysostomos2012-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new MRO stuff in 5.10 made PL_sub_generation++ mostly unnecessary, and almost all uses of it were replaced with mro_method_changed_in. There is only one problem: That doesn’t actually work properly. After glob-to-glob assignment (*foo = *bar), both globs share the same GP (glob pointer, or list of glob slots). But there is no list of GVs associated with any GP. So there is no way, given a GV whose GP is shared, to find out what other classes might need their method caches reset. sub B::b { "b" } *A::b = *B::b; @C::ISA = "A"; print C->b, "\n"; # should print "b" eval 'sub B::b { "c" }'; print C->b, "\n"; # should print "c" __END__ $ perl5.8.9 foo b c $ perl5.10.0 foo b b And it continues up to 5.16.x. If a GP is shared, then those places where mro_method_changed_in is called after the GP has been modified must do PL_sub_generation++ instead if the GP is shared, which can be detected through its refer- ence count.
* scope.c:save_gp: Remove redundant codeFather Chrysostomos2012-11-291-8/+0
| | | | | This has been redundant since ERRSV was changed to use GvSVn in com- mit f5fa9033b8.
* Remove "register" declarationsKarl Williamson2012-11-241-1/+1
| | | | | | | This finishes the removal of register declarations started by eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in function parameter declarations, and didn't include things in dist, ext, and lib, which this does include
* scope.c: Remove XXX tmp comment from SAVEt_FREEOPFather Chrysostomos2012-11-201-1/+1
| | | | | This assertion helped me to find and fix a crashing bug, so I don’t want it to be removed.
* reduce scope of a var in save_clearsvDaniel Dragan2012-11-181-1/+1
| | | | | | | | | | | | | | | | | | svp is a pointer to a pad array slice. It is derefed to set a sv flag. It's optimized scope previous extended past the savestack_grow call. By moving the flag setting before any calls in save_clearsv, svp does not have to be carried across any calls. On some platforms there will be a benefit (args transfered in vol regs for example, AMD64 Win64), on others none since it will be reread from the stack after any child call anyway. I assume the SvPADSTALE_off flag will have no effect on the panic croak. After this commit, the only auto var carried through a call is offset_shifted (and unavoidably my_perl). I saw a drop in the size of save_clearsv from 0x5A to 0x58. The saving and use of 1 nonvol reg on x86 32 bit VC 2003 was reduced, total stack frame reduced by 1 pointer, since VC 2003 read svp off the stack only once at the start of save_clearsv and kept it in a nonvol reg for the rest of this func's body.
* Stop local $_[0] from leakingFather Chrysostomos2012-11-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | local $_[0] puts the current $_[0] on to the savestack and gives the array a brand new SV. If the array is not marked REAL, it holds no reference counts on its elements. @_ is surreal by default. The localisation code was making @_ hold a reference count on its new element. The restore code was assuming it had a reference count, so everything worked out if $_[0] was not modified after localisation. But if the array is surreal, then modifications to it will assume that it does *not* hold a reference count on $_[0]. So doing shift, or @_=undef would cause the new element to leak. Also, taking a reference to the array (\@_) will trigger, making the reference count of all elements increeas, likwies leaking the new element. Since there is only one REAL flag, which indicates that all elements of the array are reference-counted, we cannot have some elements ref- erence-counted and some not (which local $_[0] does), and have every- thing behave correctly. So the only solution is to reify arrays before localising their elements.
* reindent block in leave_scopeDavid Mitchell2012-11-101-79/+79
| | | | | The previous commit added a loop round a block of code; now increase the indent of the body of the loop.
* add SAVEt_CLEARPADRANGEDavid Mitchell2012-11-101-9/+20
| | | | | Add a new save type that does the equivalent of multiple SAVEt_CLEARSV's for a given target range. This makes the new padange op more efficient.
* fix NO_TAINT_SUPPORT on g++David Mitchell2012-11-051-1/+1
| | | | A '&' got lost in the conversion
* Add C define to remove taint support from perlSteffen Mueller2012-11-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Revert "Set PL_comppad_name on sub entry"Father Chrysostomos2012-09-171-1/+0
| | | | This reverts commit d2c8bf052f5a8bb99050f6d2418d77151eb4b468.
* Make cx_dump() display the correct gimme descriptionVincent Pit2012-09-161-1/+16
| | | | Contexts are no longer what they used to be back in 1996.
* Fix perl with -DPERL_POISON after commit 22ade07Vincent Pit2012-09-161-5/+2
| | | | | The third argument to PoisonNew is the type, not the size. Also, poisoning the contents of the sv itself is incorrect.
* Save one NULL assignment per TMPSteffen Mueller2012-09-161-2/+7
| | | | | This assignment looks really rather like overzealous cleanliness. It's a hot path. Now it's death by 999 cuts instead of 1000.
* Move my sub prototype CVs to the pad namesFather Chrysostomos2012-09-151-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Set PL_comppad_name on sub entryFather Chrysostomos2012-09-151-0/+1
|
* CvNAME_HEK_setFather Chrysostomos2012-09-151-5/+3
|
* Clone my subs on scope entryFather Chrysostomos2012-09-151-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Omnibus removal of register declarationsKarl Williamson2012-08-181-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* scope.c: Don’t stringify globs on scope exitFather Chrysostomos2012-07-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a waste: /* Can clear pad variable in place? */ if (SvREFCNT(sv) <= 1 && !SvOBJECT(sv)) { /* * if a my variable that was made readonly is going out of * scope, we want to remove the readonlyness so that it can * go out of scope quietly */ if (SvPADMY(sv) && !SvFAKE(sv)) SvREADONLY_off(sv); if (SvTHINKFIRST(sv)) sv_force_normal_flags(sv, SV_IMMEDIATE_UNREF); We can simply drop the globness in sv_force_normal instead of flatten- ing globs to strings. The same applies to COWs. The SV_COW_DROP_PV flag accomplishes both. Before and after: $ time ./miniperl -e 'for (1..1000000) { my $x = *foo }' real 0m2.324s user 0m2.316s sys 0m0.006s $ time ./miniperl -e 'for (1..1000000) { my $x = *foo }' real 0m0.848s user 0m0.840s sys 0m0.005s
* eliminate PL_reg_start_tmp, PL_reg_start_tmplDavid Mitchell2012-06-131-3/+0
| | | | | | | | | | | | | | | | | | PL_reg_start_tmp is a global array of temporary parentheses start positions. An element is set when a '(' is first encountered, while when a ')' is seen, the per-regex offs array is updated with the start and end position: the end derived from the position where the ')' was encountered, and the start position derived from PL_reg_start_tmp[n]. This allows us to differentiate between pending and fully-processed captures. Change it so that the tmp start value becomes a third field in the offs array (.start_tmp), along with the existing .start and .end fields. This makes the value now per regex rather than global. Although it uses a bit more memory (the start_tmp values aren't needed after the match has completed), it simplifies the code, and will make it easier to make a (??{}) switch to the new regex without having to dump everything on the save stack.
* update the editor hints for spaces, not tabsRicardo Signes2012-05-291-2/+2
| | | | | This updates the editor hints in our files for Emacs and vim to request that tabs be inserted as spaces.
* scope.c: Simplify and clarify commentFather Chrysostomos2012-05-211-15/+2
| | | | | | | | | | | | | | This comment seems to imply that this code is just working around a problem in gv.c, which we could simply correct there. I’ve already tried making the quoted code in gv.c handle *^H without a hash, but it doesn’t actually solve the problem. The real problem is that rv2hv could also add a hash to *^H, via GvHVn, and that is simply not set up to deal with autovivifying magic at all, and probably shouldn’t be. Also, quoting a piece of code that occurs elsewhere is just asking for it to drift apart. By this time, the code in gv.c that is quoted in scope.c is actually three times the length now, and looks completely different.
* [perl #112444] Don’t leak %^H autovivified by destructorFather Chrysostomos2012-04-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | More precisely, don’t let a hint hash autovivified by a destructor during scope exit leak to outer scopes. GvHV(PL_hintgv) (aka *^H{HASH}) must be set to null before the hash in it is freed on scope exit. Otherwise destructors will see %^H with a refcount of zero, and might try to iterate over a hash that is in the process of being freed. Bad things then happen. Commit 2653c1e3b1 took care of this. Now, if GvHV(PL_hintgv) is null when destructors are called, those destructors might end up autovivifying it. The code in scope.c that handles hints when a scope is left (SAVEt_HINTS in Perl_leave_scope) would then end up leaving that new autovivified %^H in place when the scope exited, if the outer scope did not have HINT_LOCALIZE_HH set (meaning %^H was unused). That in itself would not be so much of a problem, if it were not for the fact that %^H is magicalised by the scope-handling code, not when it is autovivified (see also bug #112458). Hence, subsequent changes to %^H would not magically set the HINT_LOCALIZE_HH hint bit, which bit is checked all over the place to see whether %^H is in use. This, in turn, would cause hints subsequently added to %^H to leak to outer scopes. This commit fixes that by repeatedly freeing GvHV(PL_hintgv). If a destructor autovivifies it again, it just causes another iteration of the while loop. This does mean a destructor could autovivify %^H and cause the new %^H itself to trigger a destructor, resulting in infi- nite loops. But then that is that own code’s fault. This originally came up because commit 2653c1e3b1 also caused des- tructors that try to add new free magic to %^H to add it to a new autovivified %^H instead of the existing %^H that was being freed. This caused the nextgen module to fail its tests, because it uses B::Hooks::EndOfScope to register a sub to be called on scope exit, and it does this from a destructor itself called during scope exit. If the autovivified %^H leaks to an outer scope, the second destructor is not called.
* stop %^H pointing to being-freed hash; #112326David Mitchell2012-04-111-3/+4
| | | | | | | | | | | The leave_scope() action SAVEt_HINTS does the following to GvHV(PL_hintgv): first it SvREFCNT_dec()'s it, then sets it to NULL. If the current %^H contains a destructor, then that will be executed while %^H still points to the hash being freed. This can cause bad things to happen, like iterating over the hash being freed. Instead, setGvHV(PL_hintgv) to NULL first, *then* free the hash.
* Provide as much diagnostic information as possible in "panic: ..." messages.Nicholas Clark2012-01-161-2/+2
| | | | | | | | | | | | | | | The convention is that when the interpreter dies with an internal error, the message starts "panic: ". Historically, many panic messages had been terse fixed strings, which means that the out-of-range values that triggered the panic are lost. Now we try to report these values, as such panics may not be repeatable, and the original error message may be the only diagnostic we get when we try to find the cause. We can't report diagnostics when the panic message is generated by something other than croak(), as we don't have *printf-style format strings. Don't attempt to report values in panics related to *printf buffer overflows, as attempting to format the values to strings may repeat or compound the original error.
* Don’t double-free hint hash if copying diesFather Chrysostomos2011-12-231-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this horrendous piece of code, the attempt to clone GvHV(PL_hintgv) in save_hints dies because the NEXTKEY method cannot be found. But that happens while GvHV(PL_hintgv) still points to the old value. So the old hash gets freed in the new scope (when it unwinds due to the error in trying to find NEXTKEY) and then gets freed in the outer scope, too, resulting in the dreaded ‘Attempt to free unrefer- enced scalar’. package namespace::clean::_TieHintHash; sub TIEHASH { bless[] } sub STORE { $_[0][0]{$_[1]} = $_[2] } sub FETCH { $_[0][0]{$_[1]} } sub FIRSTKEY { my $a = scalar keys %{$_[0][0]}; each %{$_[0][0]} } # Intentionally commented out: # sub NEXTKEY { each %{$_[0][0]} } package main; BEGIN { $^H{foo} = "bar"; # activate localisation magic tie( %^H, 'namespace::clean::_TieHintHash' ); # sabotage %^H $^H{foo} = "bar"; # create an element in the tied hash } { ; } # clone the tied hint hash The solution is to set GvHV(PL_hintgv) to NULL when copying it.
View Lorry Controller Status