distribution) and setting date/time stamps of existing files to
reflect the bleadperl status.
+Note that this will not delete any files that were in '.' before
+the rsync. Once you are sure that the rsync is running correctly,
+run it with the --delete and the --dry-run options like this:
+
+ # rsync -avz --delete --dry-run rsync://ftp.linux.activestate.com/perl-current/ .
+
+This will I<simulate> an rsync run that also deletes files not
+present in the bleadperl master copy. Observe the results from
+this run closely. If you are sure that the actual run would delete
+no files precious to you, you could remove the '--dry-run' option.
+
You can than check what patch was the latest that was applied by
looking in the file B<.patch>, which will show the number of the
latest patch.
excellent point to start with when choosing to use the 'rsync the
patches' scheme. Starting with perl@7582, which means a set of source
files on which the latest applied patch is number 7582, you apply all
-succeeding patches available from than on (7583, 7584, ...).
+succeeding patches available from then on (7583, 7584, ...).
You can use the patches later as a kind of search archive.
To report a bug in Perl, use the program I<perlbug> which comes with
Perl (if you can't get Perl to work, send mail to the address
-I<perlbug@perl.com> or I<perlbug@perl.org>). Reporting bugs through
+I<perlbug@perl.org> or I<perlbug@perl.com>). Reporting bugs through
I<perlbug> feeds into the automated bug-tracking system, access to
which is provided through the web at I<http://bugs.perl.org/>. It
often pays to check the archives of the perl5-porters mailing list to
1 PP(pp_add)
2 {
- 3 djSP; dATARGET; tryAMAGICbin(add,opASSIGN);
+ 3 dSP; dATARGET; tryAMAGICbin(add,opASSIGN);
4 {
5 dPOPTOPnnrl_ul;
6 SETn( left + right );
=item break source.c:xxx
Tells the debugger that we'll want to pause execution when we reach
-either the named function (but see L</Function names>!) or the given
+either the named function (but see L<perlguts/Internal Functions>!) or the given
line in the named source file.
=item step
(gdb) break Perl_pp_add
Breakpoint 1 at 0x46249f: file pp_hot.c, line 309.
-Notice we use C<Perl_pp_add> and not C<pp_add> - see L<perlguts/Function Names>.
+Notice we use C<Perl_pp_add> and not C<pp_add> - see L<perlguts/Internal Functions>.
With the breakpoint in place, we can run our program:
(gdb) run -e '$b = "6XXXX"; $c = 2.3; $a = $b + $c'
libraries, and then:
Breakpoint 1, Perl_pp_add () at pp_hot.c:309
- 309 djSP; dATARGET; tryAMAGICbin(add,opASSIGN);
+ 309 dSP; dATARGET; tryAMAGICbin(add,opASSIGN);
(gdb) step
311 dPOPTOPnnrl_ul;
(gdb)
which would instrument Perl in memory, run Perl on test.pl,
then finally report any memory problems.
+=head2 Compaq's/Digital's Third Degree
+
+Third Degree is a tool for memory leak detection and memory access checks.
+It is one of the many tools in the ATOM toolkit. The toolkit is only
+available on Tru64 (formerly known as Digital UNIX formerly known as
+DEC OSF/1).
+
+When building Perl, you must first run Configure with -Doptimize=-g
+and -Uusemymalloc flags, after that you can use the make targets
+"perl.third" and "test.third".
+
+The short story is that with "atom" you can instrument the Perl
+executable to create a new executable called "perl.third". When the
+instrumented executable is run, it creates a log of dubious memory
+traffic in file called "perl.3log". See the manual pages of atom and
+third for more information. The most extensive Third Degree
+documentation is available in the Compaq "Tru64 UNIX Programmer's
+Guide", chapter "Debugging Programs with Third Degree".
+
+The "test.third" leaves a lot of files named perl.3log.* in the t/
+subdirectory. There is a problem with these files: Third Degree is so
+effective that it finds problems also in the system libraries.
+Therefore there are certain types of errors that you should ignore
+in your debugging. Errors with stack traces matching
+
+ __actual_atof|__catgets|_doprnt|__exc_|__exec|_findio|__localtime|setlocale|__sia_|__strxfrm
+
+(all in libc.so) are known to be non-serious. You can also
+ignore the combinations
+
+ Perl_gv_fetchfile() calling strcpy()
+ S_doopen_pmc() calling strcmp()
+
+causing "rih" (reading invalid heap) errors.
+
+There are also leaks that for given certain definition of a leak,
+aren't. See L</PERL_DESTRUCT_LEVEL> 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<does not> 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.
+The t/TEST wrapper does set this to 2, and this is what you
+need to do too, if you don't want to see the "global leaks":
+
+ PERL_DESTRUCT_LEVEL=2 ./perl.third t/foo/bar.t
+
+=head2 Pixie Profiling
+
+Pixie is a profiling tool available on IRIX and Tru64
+(aka Digital UNIX aka DEC OSF/1) platforms. Pixie does its profiling
+using "basic-block counting". A basic block is a program region that
+is entered only at the beginning and exited only at the end.
+
+You can build a profiled version of perl called "perl.pixie" by
+invoking the make target "perl.pixie" (in Tru64 a file called
+"perl.Addrs" will also be silently created, this file contains the
+addresses of the basic blocks). Running the profiled version of Perl
+will create a new file called "perl.Counts" which contains the counts
+for the basic block for that particular program execution.
+
+To display the results you must use the "prof" utility. The exact
+incantation depends on your operating system, "prof perl.Counts" in
+IRIX, and "prof -pixie -all -L. perl" in Tru64.
+
+In IRIX the following prof options are available:
+
+=over 4
+
+=item -h
+
+Reports the most heavily used lines in descending order of use.
+Useful for finding the hotspot lines.
+
+=item -l
+
+Groups lines by procedure, with procedures sorted in descending order of use.
+Within a procedure, lines are listed in source order.
+Useful for finding the hotspots of procedures.
+
+=back
+
+In Tru64 the following options are available:
+
+=over 4
+
+=item -p
+
+Procecures sorted in descending order by the number of cycles executed
+in each procedure. Useful for finding the hotspot procedures.
+(This is the default option.)
+
+=item -h
+
+Lines sorted in descending order by the number of cycles executed in
+each line. Useful for finding the hotspot lines.
+
+=item -i
+
+The called procedures are sorted in descending order by number of calls
+made to the procedures. Useful for finding the most used procedures.
+
+=item -l
+
+Grouped by procedure, sorted by cycles executed per procedure.
+Useful for finding the hotspots of procedures.
+
+=item -testcoverage
+
+The compiler emitted code for these lines, but the code was unexecuted.
+
+=item -zero
+
+Unexecuted procedures.
+
+=back
+
+For further information, see your system's manual pages for pixie and prof.
+
=head2 CONCLUSION
We've had a brief look around the Perl source, an overview of the stages
projects / p5sagit/p5-mst-13.2.git / blobdiff