Re^2: Debugging DESTROY calls in forking application

Through the power of a very aggressive code-edit script i managed to inject enough print statements i found a couple of spots in my application that would, under certain (not clearly known) circumstances, throw errors during DESTROY.

Basically, perl would DESTROY a IO::Socket::* instance, then call DESTROY on the instance that was using that socket and would try to cleanly close the connection. This would fail and raise an exception (not eval'ed) during DESTROY which would utterly confuse Perl 5.30.1 and/or the still-alive parts of my application (don't know which yet) which would result in an infinite loop.

I fixed that by enclosing those function calls in eval(). At least i hope that fixed it permanenty.

Unfortunately, one of those was in my Net::Clacks client, so everyone gets to enjoy adding another item to upgrade on their already too long list...

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

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

Replies are listed 'Best First'.
Re^3: Debugging DESTROY calls in forking application by LanX (Saint) on Mar 10, 2020 at 14:20 UTC
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}	[reply] [d/l]
Re^4: Debugging DESTROY calls in forking application by cavac (Parson) 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]


laziness, impatience, and hubris
	PerlMonks