Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPC::Open3 calls die, not exit, on exec failure #872

Closed
p5pRT opened this issue Nov 18, 1999 · 7 comments
Closed

IPC::Open3 calls die, not exit, on exec failure #872

p5pRT opened this issue Nov 18, 1999 · 7 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Nov 18, 1999

Migrated from rt.perl.org#1803 (status was 'resolved')

Searchable as RT1803$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 18, 1999

From davidb@fundsxpress.com

In IPC​::Open3.pm, version 1.0101, line 188/189, there is the following
code.

  exec @​cmd
  or croak "open3​: exec of @​cmd failed";

This code is executed after the process has forked. This has the large
problem that if you run the code in an eval block, your child process will
break out to the top of the block rather than die.

This caused a big problem for us, because we have code that runs in a
loop and executes functions in eval blocks. The parent process was executing
an open3 command and the program to run wasn't in the path. The exec
in the child process failed and the child process dropped back to the
end of the eval in the loop. The parent sat waiting for the child to
terminate, and the child kept running in the loop. The next phase of
the loop caused the same problem, and this kept happening until we had
40 copies of the application running and the server ran out of memory.

An easy solution to this problem is to make line 188 of Open3.pm print
the error to STDERR and call exit rather than calling croak. The Open3
caller can then check the STDERR for the error.

Perl Info


Site configuration information for perl 5.00503:

Configured by hartmans at Mon Nov  1 07:02:21 CST 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=dec_osf, osvers=4.0, archname=alpha-dec_osf
    uname='osf1 utwig v4.0 878 alpha '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=define d_sfio=define
  Compiler:
    cc='cc', optimize='-O4', gccversion=
    cppflags='-std -ieee -D_INTRINSICS -I/prod/devtrees/hartmans/tools/sfio/include -I/usr/local/include -I/mesa/myarch/include -DLANGUAGE_C'
    ccflags ='-std -fprm d -ieee -D_INTRINSICS -I/prod/devtrees/hartmans/tools/sfio/include -I/usr/local/include -I/mesa/myarch/include -DLANGUAGE_C'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=8, ptrsize=8, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='ld', ldflags =' -L/prod/devtrees/hartmans/tools/sfio/src/lib/sfio -L/usr/local/lib'
    libpth=/prod/devtrees/hartmans/tools/sfio/src/lib/sfio /usr/local/lib /usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /var/shlib
    libs=-lsfio -ldbm -ldb -lm
    libc=/usr/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='  -Wl,-rpath,/mesa/arch/alpha_osf1/lib/perl5/5.00503/alpha-dec_osf/CORE'
    cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -s -L/prod/devtrees/hartmans/tools/sfio/src/lib/sfio -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /mesa/arch/alpha_osf1/lib/perl5/5.00503/alpha-dec_osf
    /mesa/arch/alpha_osf1/lib/perl5/5.00503
    /mesa/arch/alpha_osf1/lib/perl5/site_perl/5.005/alpha-dec_osf
    /mesa/arch/alpha_osf1/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/home/davidb
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/mesa/bin:/usr/pkg/bin:/home/davidb/bin:/usr/local/bin:/usr/krb5/bin:/mesa/bin:/usr/bin:.:/usr/bin/X11:/bin::/usr/X11R6/bin:.:/usr/games/bin:/usr/contrib/bin:/bin:/usr/X11R6/bin:/home/davidb/fxdgs:/usr/sbin:/sbin:/home/davidb/cvs//bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 11, 2000

From [Unknown Contact. See original ticket]

This bug appears to still be active.

In IPC​::Open3.pm, version 1.0101, line 188/189, there is the following
code.

  exec @​cmd
  or croak "open3​: exec of @​cmd failed";

This code is executed after the process has forked. This has the large
problem that if you run the code in an eval block, your child process will
break out to the top of the block rather than die.

This caused a big problem for us, because we have code that runs in a
loop and executes functions in eval blocks. The parent process was
executing
an open3 command and the program to run wasn't in the path. The exec
in the child process failed and the child process dropped back to the
end of the eval in the loop. The parent sat waiting for the child to
terminate, and the child kept running in the loop. The next phase of
the loop caused the same problem, and this kept happening until we had
40 copies of the application running and the server ran out of memory.

An easy solution to this problem is to make line 188 of Open3.pm print
the error to STDERR and call exit rather than calling croak. The Open3
caller can then check the STDERR for the error.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 11, 2000

From [Unknown Contact. See original ticket]

On Mon, Dec 11, 2000 at 10​:53​:36PM -0500, Stephen P. Potter wrote​:

An easy solution to this problem is to make line 188 of Open3.pm print
the error to STDERR and call exit rather than calling croak. The Open3
caller can then check the STDERR for the error.

If there are things waiting to be DESTROYed that will have effects
outside of the process, like cleaning up files or releasing locks,
then this will cause resources probably still needed by the parent to be
cleaned up by the child.

I've had to resort to "kill 9, $$" in the past to work around this, thus
immediately limiting my module's portability.

Is there any way to exit perl and skip DESTROYs? Or, better yet, to
simulate the bypassing of DESTROYs by exec()? I've had some need to
spawn coprocesses (encapsulated as a sub) which then had to kill 9, $$ to
avoid unwanted cleanups.

Both of these came up most recently in the vcp stuff I'm trying to use
to do p4->cvs replication, actually.

- Barrie

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 11, 2000

From @tonycoz

On Tue, 12 Dec 2000, barries wrote​:

Is there any way to exit perl and skip DESTROYs? Or, better yet, to
simulate the bypassing of DESTROYs by exec()? I've had some need to
spawn coprocesses (encapsulated as a sub) which then had to kill 9, $$ to
avoid unwanted cleanups.

use POSIX "_exit";
package Foo;
sub DESTROY {
  print "foo​::destroy\n";
}
package main;
$x = bless {}, "Foo";
_exit(0)

prints nothing. Maybe you want _exit().

Tony

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 12, 2000

From [Unknown Contact. See original ticket]

Barries <barries@​slaysys.com> writes​:

Is there any way to exit perl and skip DESTROYs? Or, better yet, to
simulate the bypassing of DESTROYs by exec()?

I have had some success with

exec(@​list) || exec("/bin/false");

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 2, 2004

From @smpeters

[davidb@​fundsxpress.com - Thu Nov 18 08​:47​:27 1999]​:

-----------------------------------------------------------------
[Please enter your report here]
In IPC​::Open3.pm, version 1.0101, line 188/189, there is the
following
code.

exec @​cmd
or croak "open3​: exec of @​cmd failed";

This code is executed after the process has forked. This has the
large
problem that if you run the code in an eval block, your child
process
will
break out to the top of the block rather than die.

This caused a big problem for us, because we have code that runs in
a
loop and executes functions in eval blocks. The parent process was
executing
an open3 command and the program to run wasn't in the path. The
exec
in the child process failed and the child process dropped back to
the
end of the eval in the loop. The parent sat waiting for the child
to
terminate, and the child kept running in the loop. The next phase
of
the loop caused the same problem, and this kept happening until we
had
40 copies of the application running and the server ran out of
memory.

An easy solution to this problem is to make line 188 of Open3.pm
print
the error to STDERR and call exit rather than calling croak. The
Open3
caller can then check the STDERR for the error.

 
Based on the comments, the suggested solution you have would have the
side effect of running DESTROY in various other objects. The comments
have also provided a few different solutions to the problem of exiting
without running the DESTROYs. My guess, however, is that changing
this functionality now may break things that depend on the current
functionality.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 2, 2004

@smpeters - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant