On Thu, Apr 16, 2009 at 08:34:16PM +0100, David Cantrell wrote:
On Thu, Apr 16, 2009 at 07:44:39PM +0100, David Cantrell wrote:
On Thu, Apr 16, 2009 at 06:32:08PM +0100, Paul LeoNerd Evans wrote:
On Thu, Apr 16, 2009 at 06:18:45PM +0100, David Cantrell wrote:
Anyone recommend a module to
Abigail writes:
On Thu, Apr 16, 2009 at 08:34:16PM +0100, David Cantrell wrote:
eval {
if(my $pid = fork()) { # parent
local $SIG{ALRM} = sub {
kill 9, $pid; # quit RIGHT FUCKING NOW
die(Child process timed out\n);
};
David Cantrell wrote:
On Thu, Apr 16, 2009 at 07:44:39PM +0100, David Cantrell wrote:
On Thu, Apr 16, 2009 at 06:32:08PM +0100, Paul LeoNerd Evans wrote:
On Thu, Apr 16, 2009 at 06:18:45PM +0100, David Cantrell wrote:
Anyone recommend a module to give me something like
On Fri, Apr 17, 2009 at 09:24:01AM +0100, Matt Lawrence wrote:
I recently discovered that die() inside a signal handler causes a memory
leak. I don't know if that would be a problem for you in this case.
Hmm, that's not good. Have you been able to nail it down sufficiently to make
a bug
Nicholas Clark wrote:
On Fri, Apr 17, 2009 at 09:24:01AM +0100, Matt Lawrence wrote:
I recently discovered that die() inside a signal handler causes a memory
leak. I don't know if that would be a problem for you in this case.
Hmm, that's not good. Have you been able to nail it down
On Fri, Apr 17, 2009 at 09:24:01AM +0100, Matt Lawrence wrote:
David Cantrell wrote:
I ended up doing ...
eval {
if(my $pid = fork()) { # parent
local $SIG{ALRM} = sub {
kill 9, $pid; # quit RIGHT FUCKING NOW
die(Child process timed
Matt Lawrence writes:
I recently discovered that die() inside a signal handler causes a
memory leak.[...] I guess that might be related to the problem you
were having before timing out system().
Unlikely. Internally, system() forks a child process which execs a
suitable program. The parent
On Fri, Apr 17, 2009 at 11:25:54AM +0100, Matt Lawrence wrote:
I haven't had a chance to test any of this on the latest perl, 5.8.8 is
the latest I've tried it with.
Odd, I'm on 5.8.8 and don't seem to be seeing the same behaviour:
$ perl sigdie.pl
[1] 14327
$ ps -Fp 14327
UIDPID
Aaron Crane wrote:
Matt Lawrence writes:
I recently discovered that die() inside a signal handler causes a
memory leak.[...] I guess that might be related to the problem you
were having before timing out system().
Unlikely. [...]
There's an additional problem when the underlying
Chisel Wright wrote:
On Fri, Apr 17, 2009 at 11:25:54AM +0100, Matt Lawrence wrote:
I haven't had a chance to test any of this on the latest perl, 5.8.8 is
the latest I've tried it with.
Odd, I'm on 5.8.8 and don't seem to be seeing the same behaviour:
[...]
Oooh, but
On Fri, Apr 17, 2009 at 12:30:17PM +0100, Matt Lawrence wrote:
I've just verified that both cases leak on my system. Is it definitely
the same version of perl in each case?
Good point.
perl == /opt/.../bin/perl
It's compiled in-house, v5.8.8
/usr/bin/perl is the system perl:
On Fri, Apr 17, 2009 at 11:25:54AM +0100, Matt Lawrence wrote:
Nicholas Clark wrote:
On Fri, Apr 17, 2009 at 09:24:01AM +0100, Matt Lawrence wrote:
I recently discovered that die() inside a signal handler causes a memory
leak. I don't know if that would be a problem for you in this
On Thu, Apr 16, 2009 at 06:18:45PM +0100, David Cantrell wrote:
Anyone recommend a module to give me something like system(@list) but
with a timeout?
Does IPC::Run have something suitable? I seem to recall it has quite a
lot of interesting things to fiddle with...
--
Paul LeoNerd Evans
On Thu, Apr 16, 2009 at 06:32:08PM +0100, Paul LeoNerd Evans wrote:
On Thu, Apr 16, 2009 at 06:18:45PM +0100, David Cantrell wrote:
Anyone recommend a module to give me something like system(@list) but
with a timeout?
Does IPC::Run have something suitable? I seem to recall it has quite a
14 matches
Mail list logo
