| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This was due to my failure to realize that this 'if' needed to
be updated when the /aa modifier was added.
|
|
|
|
|
| |
This was due to my oversight in not fixing this switch statement
to accommodate /aa when it was added.
|
| |
|
|
|
|
| |
3c97495f56fb647c used bzero(), which isn't available on some platforms.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Because read_meta is also used to read META.* for configure_requires,
it must not return undef when dynamic_config is true. Instead,
the caller of read_meta must check dynamic_config when appropriate.
This is an API change, but as this is a new function, I think getting
correct semantics is more important than preserving back compatibility.
|
|
|
|
|
|
|
| |
It should not check MYMETA if for some reason configure_requires
is checked again after MYMETA has been created.
This patch adds a regex filter to the check for the meta file.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(aka Fun with Hash::Util)
This script gives ‘Modification of a read-only value’:
use Hash::Util lock_value;
*foo::; # autovivify
lock_value %::, foo::::;
*foo:: = [];
So far so good. That’s to be expected. But this one crashes:
use Hash::Util lock_value;
$a{h} = *foo;
lock_value %a, h;
$a{h} = [];
Under debugging builds, it gives assertion failures.
Anyone who knows how the flags work will see immediately what’s wrong,
but for the sake of those who don’t:
The SVf_FAKE flag is set on a copy of a typeglob, meaning that assign-
ing something other than a glob to it will overwrite the glob, instead
of writing to one of its slots.
The SVf_FAKE flag on a read-only (SVf_READONLY-flagged) string means
that it’s not actually read-only, but a copy-on-write string.
SVf_READONLY on a glob means that you can’t even assign *through* it.
See the first Hash::Util example above.
The crashing occurs when the two flags are combined.
sv_force_normal_flags assumes that anything marked fake AND read-only
is a copy-on-write string, so it proceeds to gut it, even if it’s
actually just corrupting a glob.
So this commit changes that check to take typeglobs into account.
|
| |
|
| |
|
| |
|
|
|
|
| |
I wonder how many other things a604c75 broke....
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I reverted the first version of this patch because I put the if()
statement before a declaration. I did a revert, rather than a correc-
tion, to make back-porting easier.
|
| |
|
|
|
|
|
|
|
|
|
| |
First, disable all the unsupported flags just to make sure they aren't
triggering something they shouldn't be. Also, zero the pglob struct
before passing to bsd_glob(); it contains function pointers, and it's
safest if they are null rather than containing random stack data.
Bug reported by Clément Lecigne <clemun@gmail.com>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit eff7e72c3 (Detect incomplete caller overrides in Carp) used
this little trick for detecting a @DB::args that an overridden
caller() failed to set:
+ @args = \$i; # A sentinal, which no-one else has the address of
But there is a bug in caller(). The first time caller tries to write
to @DB::args, it calls Perl_init_dbargs first. That function checks
whether @DB::args is AvREAL, in case someone has assigned to it, and
takes appropriate measures. But caller doesn’t bother calling
Perl_init_dbargs more than once. So manually-assigned items in
@DB::args would leak, starting with the *second* call to caller.
Commit eff7e72c3 triggered that bug, resulting in a regression in
Carp, in that it started leaking. eff7e72c3 was backported to 5.12.2
with commit 97705941a4, so in both 5.12 and 5.14 Carp is affected.
This bug (the caller bug, not Carp’s triggering thereof) also affects
any caller overrides that set @DB::args themselves, if there are
alternate calls to the overridden caller and CORE::caller.
This commit fixes that by changing the if (!PL_dbargs) condition
in pp_caller to if (!PL_dbargs || AvREAL(PL_dbargs)). I.e., if
@args is either uninitialised or AvREAL then call Perl_init_dbargs.
Perl_init_dbargs also has a bug in it, that this fixes: The array not
only needs AvREAL turned off, but also AvREIFY turned on, so that
assignments to it that occur after its initialisation turn AvREAL back
on again. (In fact, Larry Wall added a comment suggesting this back
in perl 5.000.)
|
| |
|
| |
|
|
|
|
|
|
| |
This is a regression in 5.10 caused by change 23966/08ca2aa38a29,
which added a bit of faulty logic. It was treating U* in the middle of
a pack template as equivalent to U0, if the input string was empty.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Correct the socketsize. Probably due to big-endian versus
little-endian, this has always worked on Intel CPUs. This
is a very very old problem, and it has been the reason I
never used gcc-4 on PA-RISC, because perl would not pass
the test suite in 64bitall.
Noticeable effects of wrong "$socksizetype" are return codes
of 0 (pass) from functions like getpeername (), but invalid
(or none) data in the returned structures or a return length
of 0 or 256. In the latter case, the length is stored in the
second part of the 64bit long and the 32bit first part is 0.
This might be true on Intel-like machines too, but the tests
will pass, as the significant part of the returned length is
in the first 32bits and a pointer to int will still see that
correct. Mind that in that case the 32bits after that might
have been overridden => can of worms.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Nicholas Clark wrote in
nntp://nntp.perl.org/20110603192458.GZ2604@plum.flirble.org:
> $ valgrind ./perl -Ilib 91880.pl
> ==5542== Memcheck, a memory error detector
...
> I think that the problem is that this code in S_run_user_filter()
>
> ENTER_with_name("call_filter_sub");
> SAVEGENERICSV(GvSV(PL_defgv));
> SAVETMPS;
> EXTEND(SP, 2);
>
>
> is putting an action on the save stack to write to an address within
> the GP of PL_defgv. However, the perl code run about 10 lines later
> frees up the GP of PL_defgv, so the scope stack now has a dangling
> pointer. 12 lines later at scope exit, the scope stack unwinding
> writes to the pointer, and nasal daemons emerge.
This commit precedes the SAVEGENERICSV with a call to save_gp, to make
sure the GP is not freed (and then a call to GvINTRO_off [set by
save_gp], so that subsequent glob assignments are not implicitly
localised).
This basically emulates what happens with ‘local *_ = \$some_scalar’,
but without the extra intermediate RV.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In @INC filters (subs returned by subs in @INC), $_ is localised to a
variable to which the next line of source code is to be assigned. The
function in pp_ctl.c that calls it (S_run_user_filter) has a pointer
to that variable.
Up till now, it was not setting the refcount or localising
$_ properly.
‘undef *_’ inside the sub would destroy the only refcount it
had, leaving a freed sv for toke.c to parse (which would crash,
of course).
In some cases, S_run_user_filter has to created a new variable. In
those cases, it was setting $_ to a mortal variable with the TEMP
flag, but with a refcount of 1, which would result in ‘Attempt to free
unreferenced scalar’ warnings if the $_ were freed by the subroutine.
This commit changes S_run_user_filter to use SAVEGENERICSV, rather
than SAVE_DEFSV, to localise $_, since the former lowers the refcount
on scope exit, while the latter does not. So now I have also made it
increase the refcount after assigning to the now-properly-localised $_
(DEFSV). I also turned off the TEMP flag, to avoid weird side effects
(which were what led me to this bug to begin with).
|
| |
|
| |
|
|
|
|
|
|
| |
Testing from 10.5 with Xcode 3 to the latest OS X works with usenm='false' but
not always with usenm='true'
(cherry picked from commit 60a655a1ee05c577268377c1135ffabc34dbff43)
|
| |
|
| |
|