Solaris problem with sigchld 
Author Message
 Solaris problem with sigchld

I am running perl 4.036 on SunOS 5.3 (Solaris).  It wasn't my choice :-)

I have a program that forks off a child and sits around monitoring the
host for user activity, killing the child if it sees any.  The program
worked fine under SunOS 4.1.3, but, it doesn't work under Solaris.  

The problem turned out to be due to System 5's interesting notion that
signal handlers should revert to default each time they are called.  The
natural solution would be to re-associate the signal with the handler
inside the handler routine.  Unfortunately, when I do this, after the
first call to the handler, the handler gets called repeatedly, some
large number of times, and then perl dies with a seg-fault.  Only one
child is forked off in this case; the remaining "signals" seem to be
phantoms.  The simple program below exhibits this behaviour.

Sun's dbx doesn't recognize the core file, and if I run the program
inside the de{*filter*}, the de{*filter*} lets the program terminate after
receiving the segv signal, and hence won't give me a stack trace.  This
is Sun's SPARCworks dbx; I can't tell you exactly which version it is,
since it doesn't appear to have an option to produce that, and the man
page doesn't say what version it is either.  Sigh.  gdb tells me the seg
fault occurred in hfetch, but since it doesn't understand the debugging
symbols, that is all it tells me (just that one function in the stack).

Here is the program:

    $SIG{'CHLD'} = 'childDied';

    sub childDied { warn ("child died\n"); $SIG{'CHLD'} = 'childDied'; }

    while (1)
    {
      fork || exec ("echo child");
      # parent
      warn ("sleeping\n");
      sleep (10);
      warn ("done sleeping\n");
    }

Under SunOS 4.1.3 it produces correct output:
    sleeping
    child
    child died
    done sleeping
[These four lines repeated indefinitely]

Under SunOS 5.3 (Solaris), it produces:

    sleeping
    child
    child died [3999 times]
    Segmentation fault

I would greatly appreciate it if

a) someone running Solaris could try this out to see if it is our
   installation or the port that is at fault.

b) someone could suggest why this is happening, since it might shed
   light on similar problems I am having with porting perl scripts to
   Solaris.

c) someone could suggest a better workaround than the one I have: to
   reset the signal handler inside the while loop, since this solution
   could easily cause us to miss sigchld signals.

If more details would be helpful I would be glad to supply them.
Thanks.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solaris 2: Merely Evil, or Actually The Anti-Christ?
                                                    -- Elizabeth Zwicky, SRI



Wed, 19 Jun 1996 00:28:17 GMT  
 Solaris problem with sigchld

: Sun's dbx doesn't recognize the core file, and if I run the program
: inside the de{*filter*}, the de{*filter*} lets the program terminate after
: receiving the segv signal, and hence won't give me a stack trace.  This

I gess that you'll have to compile PERL with -g, as the core is not
from your program but from perl itself.

I'm gonna try it on sol 2.2.
--
Regards,
.--------------------------------------------------.  .-------------.
| Antonio Vasconcelos at The Lisbon $tock Exchange |  | sysadmin &  |
|           "I DO NOT SPEAK FOR BVL !!!"           |  | perl rookie |
|-------------------------------------------------------------------|


`-_________________________________________________________________-'
X-Tagline: Huuu... I'm afraid... and if there is no next msg?



Thu, 20 Jun 1996 23:26:23 GMT  
 Solaris problem with sigchld
: I am running perl 4.036 on SunOS 5.3 (Solaris).  It wasn't my choice :-)
:
: I have a program that forks off a child and sits around monitoring the
: host for user activity, killing the child if it sees any.  The program
: worked fine under SunOS 4.1.3, but, it doesn't work under Solaris.  
:
: The problem turned out to be due to System 5's interesting notion that
: signal handlers should revert to default each time they are called.  The
: natural solution would be to re-associate the signal with the handler
: inside the handler routine.  Unfortunately, when I do this, after the
: first call to the handler, the handler gets called repeatedly, some
: large number of times, and then perl dies with a seg-fault.  Only one
: child is forked off in this case; the remaining "signals" seem to be
: phantoms.  The simple program below exhibits this behaviour.

That's strange, it worked ok on Solaris 2.2 (we don't have 2.3)
WITHOUT the sig re-associate.
With it, it core dump after 1990 'child died' and a 'memory error'
message.

Another bug of 2.3 ?????
-----------------------------------
#!/usr/local/bin/perl

$SIG{'CHLD'} = 'childDied';

sub childDied
{
        warn ("child died\n");
#       ############### $SIG{'CHLD'} = 'childDied';

Quote:
}

while (1)
{
  fork || exec ("echo child");
  # parent
  warn ("sleeping\n");
  sleep (10);
  warn ("done sleeping\n");

Quote:
}

///output///

sleeping
child
child died
done sleeping
sleeping
child
done sleeping
sleeping
child
done sleeping
sleeping
child

--
Regards,
.--------------------------------------------------.  .-------------.
| Antonio Vasconcelos at The Lisbon $tock Exchange |  | sysadmin &  |
|           "I DO NOT SPEAK FOR BVL !!!"           |  | perl rookie |
|-------------------------------------------------------------------|


`-_________________________________________________________________-'
X-Tagline: Huuu... I'm afraid... and if there is no next msg?



Thu, 20 Jun 1996 23:48:17 GMT  
 Solaris problem with sigchld

Quote:

>The problem turned out to be due to System 5's interesting notion that
>signal handlers should revert to default each time they are called.

>I would greatly appreciate it if

>c) someone could suggest a better workaround than the one I have: to
>   reset the signal handler inside the while loop, since this solution
>   could easily cause us to miss sigchld signals.

You can fix it easily by recompiling Perl after making the following
change.  I did this a few months ago and have had no problems at all
with any of the signal-intensive programs I have since written.

For each of these files: doarg.c eval.c stab.c util.c
        add the following line under '#include <signal.h>'
        #define signal(x,y) sigset((x),(y))

sigset() is a Solaris-ism that gives you sticky signals instead of the
normal SYSV signal() behavior.

Michael D'Errico



Fri, 21 Jun 1996 08:53:34 GMT  
 Solaris problem with sigchld

Quote:

>sigset() is a Solaris-ism that gives you sticky signals instead of the
>normal SYSV signal() behavior.

uh, sigset() is a svr2ism .. that was in svr3 and svr4 (and thus,
is also in solaris).  of course, under svr4, signal() and sigset()
are both front ends to sigaction() ...

.mrg.



Fri, 21 Jun 1996 16:48:10 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. More problems with Solaris SIGCHLD

2. SIGCHLD problems

3. pre-forking server: child zombies and SIGCHLD

4. SIGCHLD and read buffers

5. Catching SIGCHLD

6. SIGCHLD fun and games.

7. SIGCHLD signal on HPUX10.20

8. SIGCHLD on hpux

9. Perl daemon dumps core - SIGCHLD SIGALRM

10. Using SIGCHLD handler

11. Children killing parent SIGCHLD

12. SIGCHLD

 

 
Powered by phpBB® Forum Software