Re^3: Debugging DESTROY calls in forking application

Well that's solution for your underlying problem, but not the OP. ;)

The interested reader might want to know that Perl has also tracers in the Devel namespace.

perlrun

dt:MOD=[bar,baz] runs the program under the control of a debugging, profiling, or tracing module installed as Devel::MOD. E.g., -d:DProf executes the program using the Devel::DProf profiler. As with the -M flag, options may be passed to the Devel::MOD package where they will be received and interpreted by the Devel::MOD::import routine. Again, like -M, use --d:-MOD to call Devel::MOD::unimport instead of import. The comma- separated list of options must follow a = character. If t is specified, it indicates to the debugger that threads will be used in the code being debugged. See perldebug

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

Comment on Re^3: Debugging DESTROY calls in forking application Download Code

Replies are listed 'Best First'.
Re^4: Debugging DESTROY calls in forking application by cavac (Prior) on Mar 10, 2020 at 14:42 UTC
I tried it with -d:Trace, but all the extra stuff happening made timeouts happen which screwed up my tests. But i agree, in many cases all that build in debugging/profiling/tracing functionality is a good way to find problems. `perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'`	[reply] [d/l]
Re^5: Debugging DESTROY calls in forking application by LanX (Saint) on Mar 10, 2020 at 15:30 UTC
CPAN has a big variety of modules in `Devel::` , like Devel::Trace , Devel::ebug , etc . I'd be surprised if it wasn't possible to limit the trace to DESTROY only. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l]