From: Dave Mitchell <davem@fdisolutions.com>
Date: Sat, 16 Nov 2002 22:18:23 +0000 (+0000)
Subject: Re: [PATCH] optional code for debugging leaking scalars
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=5a6c59efdb6adbea810f12ca2ce4a559f52eca2e;p=p5sagit%2Fp5-mst-13.2.git

Re: [PATCH] optional code for debugging leaking scalars
Message-ID: <20021116221823.A23614@fdgroup.com>
Documentation for change #18150.
p4raw-link: @18150 on //depot/perl: eba0f806800ee6c16a404edf6a6aff3df57bdcb5

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

diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index fbb7c9b..023c243 100644
--- a/pod/perlhack.pod
+++ b/pod/perlhack.pod
@@ -2064,7 +2064,14 @@ For example, for "third-degreed" Perl:
 
 (Note: the mod_perl apache module uses also this environment variable
 for its own purposes and extended its semantics. Refer to the mod_perl
-documentation for more information.)
+documentation for more information. Also, spawned threads set this
+variable to the value 2.)
+
+If, at the end of a run you get the message I<N scalars leaked>, you can
+recompile with C<-DDEBUG_LEAKING_SCALARS>, which will cause
+the addresses of all those leaked SVs to be dumped; it also converts
+C<new_SV()> from a macro into a real function, so you can use your
+favourite debugger to discover where those pesky SVs were allocated.
 
 =head2 Profiling