[ARGUS] 2.0.6.fixes.1 core from improper signal handling

[slif at bellsouth.net]

Hi, Carter.
I've found an unusual occurrence that I doubt
can be recreated manually.  I think it can be prevented.

Problem:  One of the processes of the argus server
received a SIGCHLD signal during the processing of a
"C" library call, in this case "calloc".

The signal handler ArgusChildExit begins to cleanup the child,
as it is intended to do,
but dies terribly (SIGABRT) during another call to "calloc".

Apparently "calloc" is not intended to be called recursively
 :-)

Solution:
Create a new function ArgusScheduleChildExit that is wired to SIGCHLD.
It should set a program global flag, in a manner like ArgusUsr2Sig.

That flag can be used to conditionally call ArgusChildExit
from the top of the processing loop.
 [You know best which loops should include the call!]

This gives the software interrupt *caller* an opportunity to
finish its work, and return from interrupt.


Best Regards,
-Mike Slifcak

-------------- next part --------------
A non-text attachment was scrubbed...
Name: argus_signal20_gdb.out
Type: application/octet-stream
Size: 2810 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20041111/9646d687/attachment.obj>