expand -DDEBUG_LEAKING_SCALARS to instrument the creation of each SV

p4raw-id: //depot/perl@24088

1 files changed, 7 insertions, 4 deletions

diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index 5e188c08a0..78226bd662 100644
--- a/pod/perlhack.pod
+++ b/pod/perlhack.pod
@@ -2310,10 +2310,13 @@ documentation for more information. Also, spawned threads do the
 equivalent of setting this variable to the value 1.)
 
 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.
+recompile with C<-DDEBUG_LEAKING_SCALARS>, which will cause the addresses
+of all those leaked SVs to be dumped along with details as to where each
+SV was originally allocated. This information is also displayed by
+Devel::Peek. Note that the extra details recorded with each SV increases
+memory usage, so it shouldn't be used in production environments. 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