Skip Menu |

This queue is for tickets about the Devel-MAT-Dumper CPAN distribution.

Report information
The Basics
Id: 125991
Status: open
Priority: 0/
Queue: Devel-MAT-Dumper

People
Owner: Nobody in particular
Requestors: HVDS [...] cpan.org
Cc: hv [...] pirum.com
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: dump at SIGNAME
I was hoping the -dump_at_SIGI<NAME> option would provide a mechanism to grab a profile from a daemon process without having to kill it; however the injected signal handler is simply removed after dumping without restoring the original handler. Not sure if there's some reason it should be considered unsafe to continue after dumping, but a trivial test suggests the patch below (written against v0.33) would achieve what I hoped: % perl -wle 'BEGIN { $SIG{"HUP"} = "IGNORE" } use Devel::MAT::Dumper "-dump_at_SIGHUP"; print "pid $$"; sleep 2; my $a = []; push @$a, $a; print "leaked"; while (1) { sleep 5; print "still running" }' pid 15150 leaked still running Dumping to /home/hv/src/nl/perl-e.pmat because of SIGHUP still running still running ^C % Hugo --- Devel/MAT/Dumper.pm.old 2018-08-03 11:35:24.801422267 +0100 +++ Devel/MAT/Dumper.pm 2018-08-03 11:36:52.181422267 +0100 @@ -171,11 +171,12 @@ my $signal = $1; exists $SIG{$signal} or die "Unrecognised signal name SIG$signal\n"; + my $orig_handler = $SIG{$signal}; $SIG{$signal} = sub { ( my $file = $dumpfile_name ) =~ s/NNN/$next_serial++/e; print STDERR "Dumping to $file because of SIG$signal\n"; Devel::MAT::Dumper::dump( $file ); - undef $SIG{$signal}; + $SIG{$signal} = $orig_handler; kill $signal => $$; }; }
On Fri Aug 03 07:00:34 2018, HVDS wrote: Show quoted text
> I was hoping the -dump_at_SIGI<NAME> option would provide a mechanism > to grab a profile from a daemon process without having to kill it; > however the injected signal handler is simply removed after dumping > without restoring the original handler. > > Not sure if there's some reason it should be considered unsafe to > continue after dumping, but a trivial test suggests the patch below > (written against v0.33) would achieve what I hoped:
Ah; that's somewhat intentional. Most signals (SIGBUS, SIGSEGV, SIGABRT) are supposed to be fatal, so they indeed stop. There is one signal that you can use for restartable purposes, and that is SIGQUIT. In fact, I recently wrote a blog post article explaining the sort of situation it arises in: https://tech.binary.com/differential-memory-leak-analysis-with-devel-mat/ Hope that helps, -- Paul Evans
On Sat Aug 04 04:55:19 2018, PEVANS wrote: Show quoted text
> Ah; that's somewhat intentional. Most signals (SIGBUS, SIGSEGV, > SIGABRT) are supposed to be fatal, so they indeed stop.
I'd suggest that signals exist precisely to allow the program to handle their behaviour - yes, the _default_ behaviour for most of them is to be fatal, that's usually the only safe thing to do if the program has not indicated it has some particular handling for the case. Show quoted text
> There is one signal that you can use for restartable purposes, and > that is SIGQUIT.
I assume you mean "one signal that D::M::Dumper let's you use" rather than "one signal that's generically available for such use". I'm not sure I understand, though, what benefit there is from _not_ restoring the handler (in the non-QUIT case). If the program has not already modified it there will be no change of behaviour, so it feels to me as if restoring it per my patch only adds functionality. I guess I'm back to my original caveat: Show quoted text
> Not sure if there's some reason it should be considered unsafe to continue after dumping
Hugo