Perl killed after child spawn

Discussion in 'Perl Misc' started by earthwormgaz, Mar 23, 2009.

  1. earthwormgaz

    earthwormgaz Guest

    Hi,

    I'm using Perl to run some tests over night. The tests are written in C
    ++ and they spawn their own child processes.

    I'm finding that if my C++ child process bombs out with signal ABRT
    (this is on Solaris btw, with Perl v5.8.4), then Perl dies. The script
    run just says "Killed" and that's all I get out of it.

    I tried running through the Perl debugger, but that just gets killed
    too. Is there some way to make the script more resiliant to this sort
    of thing? Or is it maybe a Perl bug in this version?

    Any help would be great, I'm only vaguely familiar with Perl.

    Thanks!

    Gaz
    earthwormgaz, Mar 23, 2009
    #1
    1. Advertising

  2. earthwormgaz wrote:
    > Hi,
    >
    > I'm using Perl to run some tests over night. The tests are written in C
    > ++ and they spawn their own child processes.
    >
    > I'm finding that if my C++ child process bombs out with signal ABRT
    > (this is on Solaris btw, with Perl v5.8.4), then Perl dies. The script
    > run just says "Killed" and that's all I get out of it.
    >
    > I tried running through the Perl debugger, but that just gets killed
    > too. Is there some way to make the script more resiliant to this sort
    > of thing? Or is it maybe a Perl bug in this version?
    >
    > Any help would be great, I'm only vaguely familiar with Perl.


    I'd try
    perldoc -q trap

    --
    RGB
    RedGrittyBrick, Mar 23, 2009
    #2
    1. Advertising

  3. Can you give us a little more info through pseudo-code or still
    better, real code?
    Krishna Chaitanya, Mar 23, 2009
    #3
  4. earthwormgaz

    earthwormgaz Guest

    On 23 Mar, 14:20, Krishna Chaitanya <> wrote:
    > Can you give us a little more info through pseudo-code or still
    > better, real code?


    The Perl uses backticks to launch the C++ program, and stores the
    program output in a variable.

    I've got this lot at the top trying to catch if anything nasty
    happens, but I never see the goat message.

    $SIG{ABRT} = sub { msg("goat!!!!!!"); };
    $SIG{TERM} = sub { msg("goat!!!!!!"); };
    $SIG{SEGV} = sub { msg("goat!!!!!!"); };
    $SIG{FPE} = sub { msg("goat!!!!!!"); };
    $SIG{ILL} = sub { msg("goat!!!!!!"); };
    $SIG{INT} = sub { msg("goat!!!!!!"); };
    earthwormgaz, Mar 23, 2009
    #4
  5. Well, I don't know about the msg function but you can add the
    backticks code inside an eval block, and then check on $@? Just
    thinking aloud. Also it won't hurt to have an END block print out
    anything you want.
    Krishna Chaitanya, Mar 23, 2009
    #5
  6. earthwormgaz <> wrote:


    > (this is on Solaris btw, with Perl v5.8.4), then Perl dies. The script
    > run just says "Killed" and that's all I get out of it.

    ^^^^^^^^^^^^^^^^^^
    ^^^^^^^^^^^^^^^^^^

    That is a symptom of the "Linux OOM killer", but I thought
    Solaris didn't use memory overcommitt...

    http://developers.sun.com/solaris/articles/subprocess/subprocess.html


    > I tried running through the Perl debugger, but that just gets killed
    > too. Is there some way to make the script more resiliant to this sort
    > of thing? Or is it maybe a Perl bug in this version?



    I'd look into the possibility of running out of memory anyway.


    --
    Tad McClellan
    email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
    Tad J McClellan, Mar 23, 2009
    #6
  7. earthwormgaz

    earthwormgaz Guest

    On 23 Mar, 14:39, Krishna Chaitanya <> wrote:
    > Well, I don't know about the msg function but you can add the
    > backticks code inside an eval block, and then check on $@? Just
    > thinking aloud. Also it won't hurt to have an END block print out
    > anything you want.


    I looked at an eval block, and wrapped my backtick call in one ...

    eval {
    $result = `$testLocalBin` or die "oh bugger\n";
    }; warn $@ if $@;

    It looks like the above now. My Perl script still runs thusly ...

    bash-3.00$ ./runTests.pl
    Entering directory /tests/unittests
    Killed
    earthwormgaz, Mar 23, 2009
    #7
  8. Krishna Chaitanya wrote:
    > Can you give us a little more info through pseudo-code or still
    > better, real code?


    Here's a fish ...

    $ cat forkabort.pl
    #!/usr/bin/perl
    use strict;
    use warnings;

    print "Parent $$\n";
    my $parent_pid = $$;

    sub catch_abort {
    my $signame=shift;
    print "$$ ignoring signal $signame\n";
    }
    $SIG{ABRT} = \&catch_abort;

    my $child_pid;
    if (!defined($child_pid = fork())) {
    die "cannot fork: $!";
    } elsif ($child_pid) {
    # -------------------- PARENT process ----------------
    print "Parent $$ will now wait for child $child_pid\n";
    waitpid($child_pid, 0);
    print "Parent $$ finished waiting for child\n";
    } else {
    # --------------------- CHILD process ------------------
    print "Child $$ busy for 2s ... \n";
    sleep 2;
    print "Child $$ sending parent $parent_pid an ABORT signal ... \n";
    kill 6, $parent_pid;
    print "Child $$ busy 2s ... \n";
    sleep 2;
    print "Child $$ done.\n";
    }

    Read the docs!

    --
    RGB
    RedGrittyBrick, Mar 23, 2009
    #8
  9. On 2009-03-23 15:30, earthwormgaz <> wrote:
    > On 23 Mar, 14:39, Krishna Chaitanya <> wrote:
    >> Well, I don't know about the msg function but you can add the
    >> backticks code inside an eval block, and then check on $@? Just
    >> thinking aloud. Also it won't hurt to have an END block print out
    >> anything you want.

    >
    > I looked at an eval block, and wrapped my backtick call in one ...
    >
    > eval {
    > $result = `$testLocalBin` or die "oh bugger\n";
    > }; warn $@ if $@;
    >
    > It looks like the above now. My Perl script still runs thusly ...
    >
    > bash-3.00$ ./runTests.pl
    > Entering directory /tests/unittests
    > Killed


    You cannot catch a KILL signal. You will have to find out where the
    signal comes from. I would be very surprised if a SIGABRT to one process
    would directly cause a SIGKILL on another process. Most likely there is
    something in the test framework which causes this (catching SIGABRT and
    then sending SIGKILL to all processes in the process group?). DTrace and
    truss are probably good tools to find out what is happening.

    hp
    Peter J. Holzer, Mar 23, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeff Rodriguez
    Replies:
    23
    Views:
    1,089
    David Schwartz
    Dec 9, 2003
  2. Derek Basch
    Replies:
    2
    Views:
    1,290
    Donn Cave
    Jan 21, 2005
  3. Uwe Kubosch
    Replies:
    5
    Views:
    217
    Gary Wright
    Feb 2, 2008
  4. Ed Hames
    Replies:
    0
    Views:
    365
    Ed Hames
    Apr 16, 2008
  5. Edgardo Hames
    Replies:
    1
    Views:
    340
    Ed Hames
    May 6, 2008
Loading...

Share This Page