test memory leaks around magic get dieing

Leaks happen when newSV is allocated, but then
copy operaton dies in get magic leaving not freed
scalar around.

Most of new tests check leaks in code path executing
sv_mortalcopy which has such problem. Two cases has
the same pattern, but don't use sv_mortalcopy. Can be
found with the following command:

grep -n -A3 'newSV\>' *.c | grep -B3 sv_set
[perl #115440] Fix various leaks with fatal FETCH

Various pieces of code were creating an SV and then assigning to it
from a value that might be magical.  If the source scalar is magical,
it could die when magic is called, leaking the scalar that would have
been assigned to.

So we call get-magic before creating the new scalar, and then use a
non-magical assignment.

Also, anonhash and anonlist were doing nothing to protect the aggre-
gate if an argument should die on FETCH, resulting in a leak.
optimize memory wrap croaks, often used in MEM_WRAP_CHECK

Most perls are built with PERL_MALLOC_WRAP. This causes MEM_WRAP_CHECK
macro to perform some checks on the requested allocation size in macro
Newx. The checks are performed at the caller, not in the callee (for me
on Win32 perl the callee in Newx is Perl_safesysmalloc) of Newx.
If the check fails a "Perl_croak_nocontext("%s",PL_memory_wrap)" is done.
In x86 machine code,
"if(bad_alloc) Perl_croak_nocontext("%s",PL_memory_wrap); will be written
as "cond jmp ahead ~15 bytes", "push const pointer", "push const pointer",
"call const pointer". For each Newx where the allocation amount was not a
constant (constant folding would remove the croak memory wrap branch
compleatly), the branch takes 15-19 bytes depending on x86 compiler. There
are about 80 Newx'es in the interp (win32 dynamic linking perl) that do
the memory wrap check and have a
"Perl_croak_nocontext("%s",PL_memory_wrap)" in them after all optimizations
by the compiler.

This patch reduces the memory wrap branch from 15-19 to
5 bytes on x86. Since croak_memory_wrap is a static and a noreturn, a
compiler with IPO may optimize the whole branch to "cond jmp 32 bits
relative" at each callsite. A less optimal complier may do "cond jmp 8 bits
relative (jump past the "call S_croak_memory_wrap" instruction),
then "call S_croak_memory_wrap". Both ways are better than the current
situation. The reason why croak_memory_wrap is a static and not an export
is that the compiler has more opportunity to optimize/reduce the impact of
the memory wrap branch at the call site if the target is in the same image
rather than in a different image, which would require using the platform
specific dynamic linking mechanism/export table/etc, which often requires
a new stack frame per ABI of the platform. If a dynamic linked XS module
does not use S_croak_memory_wrap it will be removed from the image by the
C compiler. If it is included in the XS image, it is a very small block
of code and a 3 byte string litteral. A CPU cache line is typically
32 or 64 bytes and a memory read is typically 16. Cutting the
instructions by 10 to 16 bytes out of "hot code" (10 of the ~80 call
sites are pp_*) is a worthy goal. In a few places the memory wrap croak is
used explictly, not from a MEM_WRAP_CHECK, this patch converts those to use
the static. If PERL_MALLOC_WRAP is undef, there are still a couple uses of
croak memory wrap, so do not keep S_croak_memory_wrap in a ifdef
PERL_MALLOC_WRAP. Also see
http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194383.html
and [perl #115456].
Re-enable static op allocation with obslab

obslab and the removal of the op_latefree logic, which allowed static
ops, removed support for the compiler modules, which allocates ops statically.
Add an op_static flag to replace the old latefree(d) op_free logic.
perl5180delta: List mods broken by padlist changes

that have at least five dependents.
fix hash key ordering dependency in t/op/defins.t

These tests break if we change the hash function or
randomly initialize the hash seed.
fix a very subtle hash ordering dependency in op/smartkve.t

Currently our hash implementation is order dependent on insertion.

When two keys collide and have to be stored in the same bucket the
order in which they are inserted into the hash will govern the order
in which they are fetched out by things like keys() and values().

This means that a copy of such a hash may be different. It is possible
this can be fixed with a low cost, but until then you cannot rely on
two hashes with the same keys having the same ordering of those keys

Depending on the hash algorithm and the seed values used this test
would fail. By changing it so there is one initial hash and then all
tests are done on copies of that hash we avoid the problem.
fix hash order dependency in ext/B/t/b.t

Hash seed randomization causes these tests to fail occasionally.
fix a hash order dependency in t/re_funcs_u.t
fix hash key ordering dependency in t/warnings.t

Hash seed randomization causes these tests to fail occasionally.
Fix hash ordering dependency in DBM_Filter/t/int32.t

Under the filtering rules in place undef() and "" and 0 map to a
packed representation of 0.

In the StoreData call we pass in an anonymous perl (untied) hash
containing an "undef" key (which is actually treated as "") with a
value of undef(), along with a key 0 with a value of 1. This hash
will store both values as distinct key/value pairs.

When this hash is used to set up the *tied* %h1 hash both the "" key
and the 0 key will be converted into the same packed value "\0\0\0\0",
which means that whichever is last in the each() of the input hashref
will be the one stored in %h1.

This means the test breaks if we change the PL_hash_seed or the hash
implementation in such a way that "" comes before 0 in the keys of
the hash.

This patch changes the input test hash to verify that undef() => 1 is
treated the same as 0 => 1, and eliminates the potential key collision.
The reason this test was reliable in the wild is that pretty well all
perls use a 0 hash seed and the same hash function.

This test probably would have broken in other enviornments as well.
improve diagnostics of dbm_filter_util.pl by using Data::Dumper::qquote

We are testing things like packed strings. If we output the bytes raw
via diag we upset terminal layers expecting utf8, and generally output
unreadable garbage regardless. So use Data::Dumper::qqoute() to
preprocess diagnositics output.
fix a compile warning and refactor some diagnostics in regexec.c
Better documentation for internal SV types
make ext/B work with 5.16.x

The modules and tests under ext/B are notionally supposed to be
portable to older perl versions; in practice, extensive bit-rot
has occurred; often attempts have been made to add version-specific
code, which haven't actually been tested against older perl versions.

This commit does the minimum necessary to get the tests under ext/B
working with 5.16.0 and 5.16.1, threaded and unthreaded. It makes no
assertions as to whether it will work with the rest of the 5.16.x test
suite.

The side effects of this fix-up are:

* a facility has been added to OptreeCheck.pm (the test module that
checks the Concise output of various constructs) that allows
version-specific matching, e.g.:

    # 4  <$> const(PV "junk") s*      < 5.017002
    # 4  <$> const(PV "junk") s*/FOLD >=5.017002

* OptreeCheck.pm's skip mechanism was found to be broken: checkOptree()
allows you to specify skipping, but only skipped one test, even though
a single call to checkOptree() could generate multiple lines of test
output.
ext/B: remove pre-5.10 support

Expunge all conditional code that supports 5.6.x through 5.9.x,
making 5.10.0 the oldest release notionally supported.
This simplifies things considerably.

See p5p thread starting at
    Message-ID: <20121018122941.GE1908@iabyn.com>
B.xs: rationalise all methods aliased to next()

The code for B::OP::next() actually implements all B::*OP::* methods
that work by directly returning a field at a known offset in the OP
structure. Methods that can't do direct access usually have their own
body, rather than sharing with next().

However, whether a method can do direct field access is often dependent on
threading and/or perl version; so the same method is sometimes implemented
by next(), and sometimes by one or more individual method bodies. This is
all very confusing.

This commit takes all methods that *may* be implemented within next(),
and makes them always implemented by next(), using a table of data that
describes each method's offset, or -1 if it needs special handling.

This makes it a lot easier to see what's going on, and will also make it
easier to add an overlay facility, which will be coming soon.

The following commit will consolidate the remaining B::*OP methods within
next().
B.xs: move all B::*OP methods to B::OP::next

The previous commit moved all B::*OP methods capable of using direct field
offsets into next(). This commit moves the remaining B::*OP methods onto
it too (apart from oplist(), which returns a list rather than a single
item).

This simplifies the code, reduces the object size, and will also make it
easier to add an overlay facility, which will be coming soon.
start to make ext/B work with 5.14.x

This fixes up a couple of test files to work under 5.14.x.
Lots more needs fixing up to make the whole distribution work
under 5.14.x, but I've lost the will for now.,
De-globalize regcomp inversion lists.

These lists are declared at file scope so will be global unless
made static.  Actual use of these lists is via the various PL_xxx
global variables that point to them and that (except for
NonL1_Perl_Non_Final_Folds_invlist) are initialized in
Perl_re_op_compile in regcomp.c (but not in its incarnation as
ext/re/re_comp.c).

So change the lists to be static, and also skip declaring and
initializing them in ext/re/re_comp.c except for the one case that
is actually used in the extension version.