X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlhack.pod;h=2d05fc3841a07f6a1634a7042ea88e0cb8ade5ff;hb=c83084d1250c5e3fe3236f495fb04a079ccb34d8;hp=4b7e3d2f738299c6e54ca77ab13158e2b8aa6338;hpb=00bf5cd963bef6a3dffb6f796fe06e66184d13f0;p=p5sagit%2Fp5-mst-13.2.git diff --git a/pod/perlhack.pod b/pod/perlhack.pod index 4b7e3d2..2d05fc3 100644 --- a/pod/perlhack.pod +++ b/pod/perlhack.pod @@ -1216,6 +1216,14 @@ important ones are explained in L as well. Pay special attention to L for information on the C<[pad]THX_?> macros. +=head2 The .i Targets + +You can expand the macros in a F file by saying + + make foo.i + +which will expand the macros using cpp. Don't be scared by the results. + =head2 Poking at Perl To really poke around with Perl, you'll probably want to build Perl for @@ -1309,8 +1317,11 @@ blessing when stepping through miles of source code. =item print Execute the given C code and print its results. B: Perl makes -heavy use of macros, and F is not aware of macros. You'll have to -substitute them yourself. So, for instance, you can't say +heavy use of macros, and F does not necessarily support macros +(see later L). You'll have to substitute them +yourself, or to invoke cpp on the source code files +(see L) +So, for instance, you can't say print SvPV_nolen(sv) @@ -1318,11 +1329,19 @@ but you have to say print Perl_sv_2pv_nolen(sv) +=back + You may find it helpful to have a "macro dictionary", which you can produce by saying C. Even then, F won't -recursively apply the macros for you. +recursively apply those macros for you. -=back +=head2 gdb macro support + +Recent versions of F have fairly good macro support, but +in order to use it you'll need to compile perl with macro definitions +included in the debugging information. Using F version 3.1, this +means configuring with C<-Doptimize=-g3>. Other compilers might use a +different switch (if they support debugging macros at all). =head2 Dumping Perl Data Structures @@ -1798,6 +1817,12 @@ Run all the tests through the B::Deparse. Not all tests will succeed. Run F on F, F, F, F, F, F, and F tests. +=item test.valgrind check.valgrind utest.valgrind ucheck.valgrind + +(Only in Linux) Run all the tests using the memory leak + naughty +memory access tool "valgrind". The log files will be named +F. + =item test.third check.third utest.third ucheck.third (Only in Tru64) Run all the tests using the memory leak + naughty @@ -1879,6 +1904,38 @@ some common testing and debugging tools with Perl. This is meant as a guide to interfacing these tools with Perl, not as any kind of guide to the use of the tools themselves. +B: Running under 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. + +B: To minimize the number of memory leak false alarms (see +L for more information), you have to have +environment variable PERL_DESTRUCT_LEVEL set to 2. The F +and harness scripts do that automatically. But if you are running +some of the tests manually-- for csh-like shells: + + setenv PERL_DESTRUCT_LEVEL 2 + +and for Bourne-type shells: + + PERL_DESTRUCT_LEVEL=2 + export PERL_DESTRUCT_LEVEL + +or in UNIXy environments you can also use the C command: + + env PERL_DESTRUCT_LEVEL=2 valgrind ./perl -Ilib ... + +B: There are known memory leaks when there are compile-time +errors within eval or require, seeing C in the call stack +is a good sign of these. Fixing these leaks is non-trivial, +unfortunately, but they must be fixed eventually. + =head2 Rational Software's Purify Purify is a commercial tool that is helpful in identifying @@ -1887,11 +1944,6 @@ badness. Perl must be compiled in a specific way for optimal testing with Purify. Purify is available under Windows NT, Solaris, HP-UX, SGI, and Siemens Unix. -The only currently known leaks happen when there are -compile-time errors within eval or require. (Fixing these -is non-trivial, unfortunately, but they must be fixed -eventually.) - =head2 Purify on Unix On Unix, Purify creates a new Perl binary. To get the most @@ -1940,17 +1992,6 @@ which creates a binary named 'pureperl' that has been Purify'ed. This binary is used in place of the standard 'perl' binary when you want to debug Perl memory problems. -To minimize the number of memory leak false alarms -(see L), set environment variable -PERL_DESTRUCT_LEVEL to 2. - - setenv PERL_DESTRUCT_LEVEL 2 - -In Bourne-type shells: - - PERL_DESTRUCT_LEVEL=2 - export PERL_DESTRUCT_LEVEL - As an example, to show any memory leaks produced during the standard Perl testset you would create and run the Purify'ed perl as: @@ -2033,13 +2074,22 @@ standard Perl testset you would create and run Purify as: which would instrument Perl in memory, run Perl on test.pl, then finally report any memory problems. -B: as of Perl 5.8.0, the ext/Encode/t/Unicode.t takes -extraordinarily long (hours?) to complete under Purify. It has been -theorized that it would eventually finish, but nobody has so far been -patient enough :-) (This same extreme slowdown has been seen also with -the Third Degree tool, so the said test must be doing something that -is quite unfriendly for memory debuggers.) It is suggested that you -simply kill away that testing process. +=head2 valgrind + +The excellent valgrind tool can be used to find out both memory leaks +and illegal memory accesses. As of August 2003 it unfortunately works +only on x86 (ELF) Linux. 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. + +As system libraries (most notably glibc) are also triggering errors, +valgrind allows to suppress such errors using suppression files. The +default suppression file that comes with valgrind already catches a lot +of them. Some additional suppressions are defined in F. + +To get valgrind and for more information see + + http://developer.kde.org/~sewardj/ =head2 Compaq's/Digital's/HP's Third Degree @@ -2072,12 +2122,12 @@ aren't. See L for more information. =head2 PERL_DESTRUCT_LEVEL -If you want to run any of the tests yourself manually using the -pureperl or perl.third executables, please note that by default -perl B explicitly cleanup all the memory it has allocated -(such as global memory arenas) but instead lets the exit() of -the whole program "take care" of such allocations, also known -as "global destruction of objects". +If you want to run any of the tests yourself manually using e.g. +valgrind, or the pureperl or perl.third executables, please note that +by default perl B explicitly cleanup all the memory it has +allocated (such as global memory arenas) but instead lets the exit() +of the whole program "take care" of such allocations, also known as +"global destruction of objects". There is a way to tell perl to do complete cleanup: set the environment variable PERL_DESTRUCT_LEVEL to a non-zero value.