Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

the following code runs really strange and I don't know why. 
use strict;
use warnings;
use IPC::Open3;
&run;

sub run {
    while ( 1 ) {
        eval { &_run };
        print $@ if $@;
        sleep 10;
    }
}

sub _run {
    my ($wtr, $rdr, $err);
    my (@output, $pid);

    eval {
        $pid = IPC::Open3::open3($wtr, $rdr, $err, 'blubb');

        while (my $line = <$rdr>) {
            chomp($line);
            push @output, "out: $line";
        }

        close($wtr) if $wtr;
        close($rdr) if $rdr;
        close($err) if $err;
        waitpid $pid, 0;
    };

    print "$_\n" for @output;
}

[download]
If the function _run is call in a eval block then it produces every 10
seconds a new process. If it runs without eval, then it runs correctly.
I tried the same with IPC::Cmd, but there exists the same problem. 
use strict;
use warnings;
use IPC::Cmd;
&run;

sub run {
    while ( 1 ) {
        eval { &_run_cmd };
        print $@ if $@;
        sleep 10;
    }
}

sub _run_cmd {
    my( $success, $error_code, $full_buf, $stdout_buf, $stderr_buf ) =
            IPC::Cmd::run( command => 'blubb', verbose => 0 );
    print $success, "\n";
}

[download]
Why does eval makes it so strange?

Thank you for helping.

Replies are listed 'Best First'.
Re: Problems with IPC::Open3
by almut (Canon) on Nov 01, 2008 at 20:49 UTC

    I'm assuming 'blubb' doesn't exist... If so, when you call open3() not being wrapped in an eval, the forked child dies with "open3: exec of blubb failed at ./720878.pl line 23", and you're reading that message via <$rdr> (because you passed in an undefined $err handle, the child's stdout and stderr are redirected to the same handle).

    However, when you call open3() wrapped in an eval, it doesn't die with the above message, and thus your <$rdr> will wait forever. What makes things complicated is that - as the exec of blubb failed - the child lives on as a forked copy of the parent, which will start the next iteration (and another child process) after 10 seconds...

    Moral of the story: don't wrap IPC::Open3::open3() in eval to catch exec errors.

[reply]
[d/l]
[select]
      I think thats a strong bug! The child must be exited in any case after exec().
[reply]

        I agree... though, as it looks, the problem has 'already' been fixed in the version that comes with 5.10.0.

[reply]
        But how can I update IPC::Open3 on my perl 5.8.8? I don't like to install perl 5.10.0 on my production machines.
[reply]
Re: Problems with IPC::Open3
by Anonymous Monk on Nov 01, 2008 at 21:01 UTC
    Hi Monks,

    I found the problem!

    I have perl 5.8.8 installed with IPC::Open3 1.02. Now the problem is that Open3.pm just croaks if the call of exec() failed - it should call exit instead of croak: 
    168         exec @cmd # XXX: wrong process to croak from
169             or croak "$Me: exec of @cmd failed";

    [download]
    Now, there exists a IPC::Open3 with the same version - 1.02 - in perl 5.10.0, but the code is slightly different and correct: 
    265     exec @cmd or do {
266         carp "$Me: exec of @cmd failed";
267         eval { require POSIX; POSIX::_exit(255); };
268         exit 255;
269     };

    [download]
    That is really annoying! The versions are the same but the code is not identical and I have no chance to "upgrade" Open3.pm - only if I copy the code down to my disk.

    Cheers
[reply]
[d/l]
[select]
Re: Problems with IPC::Open3
by Krambambuli (Curate) on Nov 01, 2008 at 20:42 UTC
    First things first: on my WS the behavior is identical with or without eval {} around the call to _run, and every 10 seconds a new process comes to life.

    That seems actually OK, as 'blubb' doesn't produce any output and so the forked child process loops forever in 
       while (my $line = <$rdr>) {
     [...]
   }

    [download]
    Update: In the meantime, the parent process does it's work and forks a new command every 10 seconds.
    As almut has shown in his her answer, it's a child that forks a child that forks a child... and each new parent waits indefinitely.

    If I replace 'blubb' with 'echo blubb', things seem to work as I suppose you want them to.


    Krambambuli
    ---
[reply]
[d/l]

Back to Seekers of Perl Wisdom