=head1 MEMORY DEBUGGERS
-B<NOTE 1>: Running under older memory debuggers such as Purify, valgrind
-or Third Degree greatly slows down the execution: seconds become minutes,
-minutes become hours. For example as of Perl 5.8.1, the
+B<NOTE 1>: Running under older memory debuggers such as Purify,
+valgrind or Third Degree greatly slows down the execution: seconds
+become minutes, minutes become hours. For example as of Perl 5.8.1, the
ext/Encode/t/Unicode.t takes extraordinarily long to complete under
e.g. Purify, Third Degree, and valgrind. Under valgrind it takes more
than six hours, even on a snappy computer. The said test must be doing
something that is quite unfriendly for memory debuggers. If you don't
feel like waiting, that you can simply kill away the perl process.
-Roughly valgrind slows down execution by factor 10, AddressSanitizer
-by factor 2.
+Roughly valgrind slows down execution by factor 10, AddressSanitizer by
+factor 2.
B<NOTE 2>: To minimize the number of memory leak false alarms (see
L</PERL_DESTRUCT_LEVEL> for more information), you have to set the
=head2 valgrind
-The valgrind tool can be used to find out both memory leaks
-and illegal heap memory accesses. As of version 3.3.0, Valgrind only
-supports Linux on x86, x86-64 and PowerPC and Darwin (OS X) on x86 and
-x86-64). The special "test.valgrind" target can be used to run the
-tests under valgrind. Found errors and memory leaks are logged in
-files named F<testfile.valgrind>.
+The valgrind tool can be used to find out both memory leaks and illegal
+heap memory accesses. As of version 3.3.0, Valgrind only supports Linux
+on x86, x86-64 and PowerPC and Darwin (OS X) on x86 and x86-64). The
+special "test.valgrind" target can be used to run the tests under
+valgrind. Found errors and memory leaks are logged in files named
+F<testfile.valgrind>.
Valgrind also provides a cachegrind tool, invoked on perl as:
=head2 AddressSanitizer
-AddressSanitizer is a clang extension, included in clang since v3.1.
-It checks illegal heap pointers, global pointers, stack pointers and use
-after free, and is so fast that you can easily compile your debugging
-or optimized perl with it. It does not check memory leaks though.
-AddressSanitizer is available for linux, Mac OS X and soon on Windows.
+AddressSanitizer is a clang extension, included in clang since v3.1. It
+checks illegal heap pointers, global pointers, stack pointers and use
+after free errors, and is fast enough that you can easily compile your
+debugging or optimized perl with it. It does not check memory leaks
+though. AddressSanitizer is available for linux, Mac OS X and soon on
+Windows.
-You should create the perl with AddressSanitizer using:
+To build perl with AddressSanitizer, your Configure invocation should
+look like:
- sh Configure -Dcc=clang -Accflags=-faddress-sanitizer \
- -Aldflags=-faddress-sanitizer \
- -Alddlflags=-shared\ -faddress-sanitizer
+ sh Configure -des -Dcc=clang \
+ -Accflags=-faddress-sanitizer -Aldflags=-faddress-sanitizer \
+ -Alddlflags=-shared\ -faddress-sanitizer
where these arguments mean:
=item * -Dcc=clang
-If clang is in your path, otherwise point to the path of the installed or temp.
-clang with AddressSanitizer enabled.
+This should be replaced by the full path to your clang executable if it
+is not in your path.
=item * -Accflags=-faddress-sanitizer
-Instrument pointer accesses with AddressSanitizer.
+Compile perl and extensions sources with AddressSanitizer.
=item * -Aldflags=-faddress-sanitizer
-Link with AddressSanitizer.
+Link the perl executable with AddressSanitizer.
=item * -Alddlflags=-shared\ -faddress-sanitizer
-With a shared libperl.so, i.e. C<-Duseshrplib> is used, you must manually add
-C<-shared>.
+Link dynamic extensions with AddressSanitizer. You must manually
+specify C<-shared> because using C<-Alddlflags=-shared> will prevent
+Configure from setting a default value for C<lddlflags>, which usually
+contains C<-shared> (at least on linux).
=back
-See L<http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer>
+See also
+L<http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer>.
=head1 PROFILING
Under ithreads the optree is read only. If you want to enforce this, to
check for write accesses from buggy code, compile with
-C<-DPL_OP_SLAB_ALLOC> to enable the OP slab allocator and
C<-DPERL_DEBUG_READONLY_OPS> to enable code that allocates op memory
-via C<mmap>, and sets it read-only at run time. Any write access to an
-op results in a C<SIGBUS> and abort.
+via C<mmap>, and sets it read-only when it is attached to a subroutine. Any
+write access to an op results in a C<SIGBUS> and abort.
This code is intended for development only, and may not be portable
even to all Unix variants. Also, it is an 80% solution, in that it
=item * 1
-Only sets read-only on all slabs of ops at C<CHECK> time, hence ops
-allocated later via C<require> or C<eval> will be re-write
+Does not apply to op slabs belonging to C<BEGIN> blocks.
=item * 2
Turns an entire slab of ops read-write if the refcount of any op in the
-slab needs to be decreased.
+slab needs to be increased or decreased. This means that anonymous
+closures will never have read-only ops, and thread creation will make all
+existing ops read-write.
=item * 3
requiring read-write access, as either can happen during op tree
building time, so there may still be legitimate write access.
-However, as an 80% solution it is still effective, as currently it
-catches a write access during the generation of F<Config.pm>, which
-means that we can't yet build F<perl> with this enabled.
+However, as an 80% solution it is still effective, as currently it catches
+the setting of breakpoints in the debugger and some XSUB definitions.
=head2 The .i Targets
make foo.i
-which will expand the macros using cpp. Don't be scared by the results.
+which will expand the macros using cpp. Don't be scared by the
+results.
=head1 AUTHOR
https://perl5.git.perl.org / perl5.git / blobdiff