From: Artur Bergman <sky@nanisky.com>
Date: Tue, 4 Mar 2003 01:01:07 +0000 (+0000)
Subject: Fixes bug #15654 bizarre constant mangling in 5.8.0
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=3b1c21fabed159100271bd60bac3f870f5ac16af;p=p5sagit%2Fp5-mst-13.2.git

Fixes bug #15654 bizarre constant mangling in 5.8.0
What happened was that a constant was freed, the pad released but
the pad slot still held the SV, when pad slot was reallocated
to be a target for a stringify, it did a sv_setpv on the target
and the original SV was wiped out. When this SV was later on
to new places using the constant, they got the wrong value.
By replacing pad_free with pad_swipe for these cases, we
won't have such a problem. (pad_swipe also removes the
pointer to the original SV).

p4raw-id: //depot/perl@18820
---

diff --git a/op.c b/op.c
index 2a7583e..f015618 100644
--- a/op.c
+++ b/op.c
@@ -299,6 +299,18 @@ Perl_op_clear(pTHX_ OP *o)
     case OP_CONST:
 	SvREFCNT_dec(cSVOPo->op_sv);
 	cSVOPo->op_sv = Nullsv;
+#ifdef USE_ITHREADS
+	/** Bug #15654
+	  Even if op_clear does a pad_free for the target of the op,
+	  pad_free doesn't actually remove the sv that exists in the bad
+	  instead it lives on. This results in that it could be reused as 
+	  a target later on when the pad was reallocated.
+	**/
+        if(o->op_targ) {
+          pad_swipe(o->op_targ,1);
+          o->op_targ = 0;
+        }
+#endif
 	break;
     case OP_GOTO:
     case OP_NEXT: