Don’t leak when partly iterated glob op is freed

File::Glob keeps its own hash of arrays of file names.  Each array corresponds to one call site.  When iteration finishes, it deletes
the array.  But if iteration never finishes, and the op at the call
site is freed, the array remains.  So eval "scalar<*>" will cause a
memory leak.

We already have a mechanism for hooking the freeing of ops.  So
File::Glob can use that.
Fix problems with -Dr during global destruction

$ cat foo
my $x = '(?{1})';
BEGIN { $^H |= 0x00200000 } # lightweight "use re 'eval'"
"a" =~ /a$_/ for $x;

If I run this under PERL_DESTRUCT_LEVEL=2 with the -Dr flag on a non-
threaded build, the output ends with this:

 during global destruction.
 during global destruction.
 during global destruction.
 during global destruction.
 during global destruction.
Attempt to free temp prematurely: SV 0x822610 during global destruction.
Attempt to free temp prematurely: SV 0x802340 during global destruction.
Attempt to free temp prematurely: SV 0x8222d0 during global destruction.
Attempt to free temp prematurely: SV 0x822490 during global destruction.
Attempt to free temp prematurely: SV 0x8224f0 during global destruction.
Scalars leaked: 5

And sometimes I even get assertion failures.  (I suspect hash random-
isation gives me the inconsistent results.)

t/re/recompile.t happened to trigger this bug, producing noisy output.
Since the assertion failures were in sub-processes, the tests passed
anyway.  In this commit I have changed the test to check the status of
the sub-processes, too, before reporting a pass.

This bug appears to have started happening in v5.17.0-424-gd24ca0c,
but I don’t know why.  I suspect it was a latent bug waiting
to happen.

During global destruction, all objects are freed, the main stash is
freed, and then various SVs in interpreter variables are also freed.
Finally, if PERL_DESTRUCT_LEVEL is set, there is one last sweep of all
remaining SVs.  It is during that sweep that this bug occurs.

When the -Dr flag is present, freeing a regular expression causes the
${^RE_DEBUG_FLAGS} flags variable to be looked up.

Symbol lookup can trigger the ‘Global symbol requires package name’
error (which becomes a warning here, due to the way pp_ctl.c:qerror
works).  The code that produces that error assumes that if there is
no stash then the preceding code has detected an attempted stricture
violation.

The preceding code actually tries to provide PL_defstash (aka %main::)
as the stash to look in, since this is a punctuation variable.  But
PL_defstash has been set to null.

The logic that no stash equals a stricture violation is there-
fore faulty.

The attempt to output that error message uses a temporary scalar which
is placed on the mortals stack.  Freeing of the items on the mortals
stack happens before this SV sweep, and not during or afterwards, so
the SV sweep ends up trying to free those mortals itself.  There is a
check in sv_free2, enabled under debugging builds, to see whether the
SV is on the mortals stacking.  If it is, a warning is emitted and the
SV is not freed.

My initial attempt at fixing this was to try to avoid putting a mortal
on the stack in this case.  The code in question doesn’t actually need
to use the mortals stack, since Perl_mess isn’t going to croak, so it
can free the SV itself.  That takes care of the ‘Attempt to free temp
prematurely’ warnings and the final ‘Scalars leaked’.  It doesn’t
solve the ‘during global destruction’ message, but I decided to leave
it in place anyway, since creating an SV and freeing it is a little
more efficient that creating it, pushing it on to the mortals stack,
and having FREETMPS free it later.

That ‘during global destruction’ message is supposed to say ‘Global
symbol...’, but diagnostic messages during global destruction use the
same SV, so it’s not suprising that it gets stomped on before it makes
its way to qerror.  I’m not sure where it gets stomped on, but it’s
not relevant; we need to get rid of the message altogether.

The final solution is to skip the ‘Global symbol...’ error altogether
while sv_clean_all (the final SV sweep) is being called, which we can
detect based on whether PL_in_clean_all is set.
Stop DynaLoader.t from unload File::Glob

File::Glob now sets PL_opfreehook.  That means that if we unload it we
will leave PL_opfreehook pointing to an invalid address, resulting in
a crash when ops are freed.

I didn’t catch this because the tests are skipped on darwin.  They
don’t actually need to be, at least under recent versions, so I modi-
fied the skip code.
fix warning in PmopSTASH_set()

In the threaded version of PmopSTASH_set(), the assigned value is a
PADOFFSET, not a pointer; so use 0 rather than NULL for the default value.

This keeps clang happy.
perldelta for 34213185

I considered more detail here, but the discussion in the ticket
covers it.
Update Digest-SHA to CPAN version 5.80

  [DELTA]

  5.80  Mon Dec 10 14:15:26 MST 2012
    - obtained noticeable speedup on Intel/gcc
        -- by setting -O1 and -fomit-frame-pointer
        -- SHA-1 about 63% faster, SHA-2 improves 11-20%
DosGlob: Don’t leak when caller’s op tree is freed

File::DosGlob keeps its own hash of arrays of file names.  Each array
corresponds to one call site.  When iteration finishes, it deletes
the array.  But if iteration never finishes, and the op at the call
site is freed, the array remains.  So eval "scalar<*>" will cause a
memory leak under the scope of ‘use File::DosGlob "glob"’.

We already have a mechanism for hooking the freeing of ops.  So
File::DosGlob can use that.

This is similar to 11ddfebc6e which fixed up File::Glob, but that com-
mit mistakenly used a C static for storing the old hook, even though
PL_opfreehook is an interpreter variable, not a global.  (The next
commit will fix that.)
Glob.xs: PL_opfreehook is an interpreter variable

Hence, there is no need to lock a mutex; also storing the old value
in a C static is bad.  It needs to be in a spot local to the current
interpreter, which MY_CXT provides.
regexec.c: silence compiler warning

The code was mixing signed and unsigned types
t/op/lex.t: Fix test

It was a copied-and-pasted repeat of another test, both of which I
added in commit 67a057d6d.  I know it used to crash and the commit
fixed it, as I tested it at the time with one-liners.
scalar(%h = (1,1,1,1)) should return 4, not 2

perldoc perlop says:

    a list assignment in scalar context returns the number of elements
    produced by the expression on the right hand side of the assignment

Behaviour was changed as side effect of
ca65944e8ff8fff6e36ea7476ba807be16cfe2a9 where goal was to fix
return value in list context.
test "Odd number of elements in hash assignment"
warn on ($s,%h) = (1,{}) as on %h = {}

Latter results in "Reference found where even-sized list expected"
message while former produces "Reference found where even-sized list
expected". Quite inconsistent.
test hash assignment with odd elements for leaks

if key scalar is tied and dies on fetch then hash assignment
is leaking a key value
fix issues in hash assignment with odd elements

1) unify code path of processing odd case with regular
loop that process pairs. fixes memory leak when key
is magic and dies on fetch.

2) in list context put undef that we added to compensate
odd elements into returned values, so (%h = (1))
returns (1, $h{1}) rather than (1). This is documented
in perldoc perlop:

    a list assignment in list context produces the list
    of lvalues assigned to.

Here can be a dispute, but:

* that key without value on RHS is still assigned with
  undef
* consider (%h = (1,2,3,4,5,6,3)). Returning (1,2,3,undef,5,6)
  is much easier than (1,2,5,6,3).
* order of returned elements follows cases with even number
  of elements on RHS and duplicates

3) hash assignment with duplicates and odd elements on
RHS was returning wrong results in list context.
Now (%h = (1,1,1)) returns (1,$h{1}).
make sure hash assignment is proper lvalue
hash assign in list context should copy key as well

if we don't then returned keys are aliases for RHS
values and can result in unexpected changes
test return values of aassign with various elements on LHS

* hash on LHS followed by array, other hash or scalar,
  for example (%h, @a) = (...);

* above with normal RHS, with duplicates, odd elements
  and combination.

* inspect elements returned by aassign for lvaluedness

* assign doesn't return elements that were just cleared
we need duplicates counter only in list context
ary/hash/firsthashelem should be set only once

Only once for first hash or array, otherwise
(%h,@a) = ... assignment returns wrong results
for duplicates and/or number of elements on RHS.