Fix for anon-lists with tied entries coredump

[George Hartlieb, a MLDBM user reported this problem in private mail.]

The following hypothetical construct:

   for $k (keys %o) {
       foo([$o{$k}]);
   }

coredumps reliably when %o is a tied hash and the FETCH for the
value $o{$k} is substantial enough to cause a stack reallocation.

Patch against 3_19 attached.

 - Sarathy.
   gsar@engin.umich.edu

P.S: Whatever happened to the stack-of-stacks patch?  Even the first
version of that patch would have eliminated this problem.  There may
be many more places where such a fix may be necessary--it's impossible
to find them all.  Please, let's atleast include a #ifdef-ed version
of that patch!

p5p-msgid: <199701100745.CAA13057@aatma.engin.umich.edu>

1 files changed, 4 insertions, 3 deletions

diff --git a/pp.c b/pp.c
index 7a24843f5d..e4e00ce948 100644
--- a/pp.c
+++ b/pp.c
@@ -2110,10 +2110,11 @@ PP(pp_lslice)
 
 PP(pp_anonlist)
 {
-    dSP; dMARK;
+    dSP; dMARK; dORIGMARK;
     I32 items = SP - MARK;
-    SP = MARK;
-    XPUSHs((SV*)sv_2mortal((SV*)av_make(items, MARK+1)));
+    SV *av = sv_2mortal((SV*)av_make(items, MARK+1));
+    SP = ORIGMARK;		/* av_make() might realloc stack_sp */
+    XPUSHs(av);
     RETURN;
 }