Bug #57186 for IPC-Run: undef warning under perl -w when fork ENOMEM

Mon May 03 19:48:25 2010 user42 [...] zip.com.au - Ticket created

Subject:	undef warning under perl -w when fork ENOMEM
Date:	Tue, 04 May 2010 09:46:55 +1000
To:	bug-IPC-Run [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

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 :-).

#!/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;

Wed May 05 09:35:39 2010 TODDR [...] cpan.org - Correspondence added

On Mon May 03 19:48:25 2010, user42@zip.com.au wrote: Show quoted text

> 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?

Wed May 05 09:35:42 2010 The RT System itself - Status changed from 'new' to 'open'

Fri May 07 20:23:23 2010 user42 [...] zip.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #57186] undef warning under perl -w when fork ENOMEM
Date:	Sat, 08 May 2010 10:23:02 +1000
To:	bug-IPC-Run [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

"Todd Rinaldo via RT" <bug-IPC-Run@rt.cpan.org> writes: Show quoted text

> > 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. Show quoted text

> 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. Show quoted text

> 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().

Thu May 13 20:43:04 2010 TODDR [...] cpan.org - Correspondence added 20 min

Show quoted text

> > 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

Thu May 13 20:43:07 2010 TODDR [...] cpan.org - Given to TODDR

Thu May 13 20:44:07 2010 TODDR [...] cpan.org - Severity Wishlist added

Thu May 13 20:44:07 2010 TODDR [...] cpan.org - Broken in 0.89 added

Thu May 13 20:44:17 2010 TODDR [...] cpan.org - Status changed from 'open' to 'stalled'

Fri May 14 17:58:30 2010 user42 [...] zip.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #57186] undef warning under perl -w when fork ENOMEM
Date:	Sat, 15 May 2010 07:58:04 +1000
To:	bug-IPC-Run [...] rt.cpan.org
From:	Kevin Ryde <user42 [...] zip.com.au>

"Todd Rinaldo via RT" <bug-IPC-Run@rt.cpan.org> writes: Show quoted text

> > 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.

Fri May 14 17:58:33 2010 The RT System itself - Status changed from 'stalled' to 'open'

Fri May 12 08:57:43 2017 TODDR [...] cpan.org - Correspondence added

Ticket migrated to github as https://github.com/toddr/IPC-Run/issues/82

Fri May 12 08:57:53 2017 TODDR [...] cpan.org - Status changed from 'open' to 'resolved'