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.

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

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.

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

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

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");

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.

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