undef warning under perl -w when fork ENOMEM [rt.cpan.org #57186]

[toddr]

Migrated from rt.cpan.org#57186 (status was 'open')

Requestors:

• [email protected]

Attachments:

• foo.pl

From [email protected] on 2010-05-03 23:48:25:

With recent debian i386 perl 5.10.1 and IPC::Run 0.89, if fork() fails
due to ENOMEM then IPC::Run::run() prints a warning.  For example the
program foo.pl below run as

    perl -w foo.pl

gets

    Use of uninitialized value in length at /usr/share/perl5/IPC/Run.pm line 3157.

where I hoped it would not do that, but only throw "Cannot allocate
memory during fork" or whatever.

The size of process that cannot fork of course depends on how much ram
and swap you've got.  The 100e6 / 4 in the program uses up about
100Mbytes on a 32-bit system, increase as necessary :-).

From [email protected] on 2010-05-05 13:35:39:

On Mon May 03 19:48:25 2010, [email protected] wrote:
> With recent debian i386 perl 5.10.1 and IPC::Run 0.89, if fork() fails
> due to ENOMEM then IPC::Run::run() prints a warning.  For example the
> program foo.pl below run as
> 
>     perl -w foo.pl
> 
> gets
> 
>     Use of uninitialized value in length at
> /usr/share/perl5/IPC/Run.pm line 3157.
> 
> where I hoped it would not do that, but only throw "Cannot allocate
> memory during fork" or whatever.
> 
> The size of process that cannot fork of course depends on how much ram
> and swap you've got.  The 100e6 / 4 in the program uses up about
> 100Mbytes on a 32-bit system, increase as necessary :-).
> 

So my son just spilled my coffee so I'm not quite awake yet and I could be missing 
something.

1. If you're out of memory, then everything is going to misbehave. What would you like to see 
happen instead?
2. Isn't this a core perl issue with how it handles out of memory, rather than IPC::Run?
3. Are you trying to do ipc::run after the failed fork for some reason? If a fork fails, it's kinda 
a fatal thing isn't it?

From [email protected] on 2010-05-08 00:23:23:

"Todd Rinaldo via RT" <[email protected]> writes:
>
> 1. If you're out of memory, then everything is going to misbehave. What would you like to see 
> happen instead?

I wasn't really out of memory, I had a process of about 140Mb and only
100Mb memory left (and no swap), so fork() decided it would not
duplicate 140Mb.  I hoped for just the fork error, not an "undef
something" warning too.

> 2. Isn't this a core perl issue with how it handles out of memory, rather than IPC::Run?

Not as far as I can tell, it seems to be only IPC::Run's behaviour when
fork() returns an error.

> 3. Are you trying to do ipc::run after the failed fork for some reason? If a fork fails, it's kinda 
> a fatal thing isn't it?

In the bit of code I was doing I didn't mind if it's not possible to run
a program -- just tell the user and continue.


The warning seems to be from _cleanup() at the line

    if ( ! length $kid->{PID} ) {

I suppose $kid->{PID} is from spawn() doing

    $kid->{PID} = fork();

which I think is undef if fork is unsuccessful.  I wonder if the test
should be defined() instead of length().  length() would be for when an
error return is an empty string, is it?, as opposed to undef from
fork().

From [email protected] on 2010-05-14 00:43:04:

> > 3. Are you trying to do ipc::run after the failed fork for some
> reason? If a fork fails, it's kinda
> > a fatal thing isn't it?
> 
> In the bit of code I was doing I didn't mind if it's not possible to
> run
> a program -- just tell the user and continue.
> 
> 
> The warning seems to be from _cleanup() at the line
> 
>     if ( ! length $kid->{PID} ) {
> 
> I suppose $kid->{PID} is from spawn() doing
> 
>     $kid->{PID} = fork();
> 
> which I think is undef if fork is unsuccessful.  I wonder if the test
> should be defined() instead of length().  length() would be for when
> an
> error return is an empty string, is it?, as opposed to undef from
> fork().


Line 1362-3 from lib/IPC/Run.pm says this:

   $kid->{PID} = fork();
   croak "$! during fork" unless defined $kid->{PID};

The only situation where fork would return undef is if the fork failed. In the event fork fails, 
the program should "die of errors (from perspective of caller)". 

This is the only instance in the code of a fork, so this is the only place where the code would 
have to be handled. the subroutine run does not eval the call so the error should fall through 
to your calling of IPC::Run::run. As a result, I would assert this is a core perl issue if at all.

Unless I hear from you, I'm going to close this ticket as a not relevant.

Thanks for the report,
Todd

From [email protected] on 2010-05-14 21:58:30:

"Todd Rinaldo via RT" <[email protected]> writes:
>
> the subroutine run does not eval the call

But I see start() does an eval{} around the _spawn().  It pushes
"caught" onto @errs then does a kill_kill(), which reaches _cleanup()
with $kid->{PID} undef.


I suppose you'd be tempted to do cleanups in a DESTROY handler instead
of trying to catch the exits -- just the one in _do_kid_and_exit to stop
the child running any cleanups.

[toddr]

foo.pl

#!/usr/bin/perl -w

use strict;
use warnings;
use IPC::Run;
use Data::Dumper;

my @x;
$#x = 100e6 / 4;
print scalar(@x),"\n";

my $pid = fork();
print Data::Dumper->new([\$pid],['pid'])->Dump;

my $out;
IPC::Run::run (['echo', 'hello']);

print "done\n";
exit 0;

[toddr]

I ran foo.pl and got:

$>perl foo.pl
25000001
$pid = \9867;
$pid = \0;
hello
done
hello
done