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

[Carter Bullard]

I'd like to see if we can make the signal handler's
a bit more immune to resource problems, so that we can
have some probability of surviving the system error.

So what do you think happened in your case, did argus
run out of memory?

Carter

> From: <slif at bellsouth.net>
> Date: Thu, 11 Nov 2004 9:37:11 -0500
> To: Carter Bullard <carter at qosient.com>
> Cc: Argus <argus-info at lists.andrew.cmu.edu>
> Subject: [ARGUS] Re: Re: 2.0.6.fixes.1 core from improper signal handling
> 
> My bad.  The death spiral begins at free(),
> not a second calloc() as I described.
>   [I guess i haven't had my second cup of coffee yet!]
> 
> Since calloc() and free() manage memory, I can imagine
> that calloc() hadn't made the list tidy before
> free() came along.
> 
> I think the proposed solution is still valid.
>   [Set flag in ISR, check flag in loop]
> 
> I can imagine the flag should be checked before the
> each opportunity to check for input.
> 
> 
> -Mike
> 
> 
>> 
>> From: Carter Bullard <carter at qosient.com>
>> Date: 2004/11/11 Thu AM 08:46:21 EST
>> To: <slif at bellsouth.net>
>> CC: Argus <argus-info at lists.andrew.cmu.edu>
>> Subject: Re: 2.0.6.fixes.1 core from improper signal handling
>> 
>> Hmmmmm, just reacting without looking at the code, why
>> is ArgusChildExit calling calloc()?
>> Carter
>> 
>> 
>> 
>> 
>>> From: <slif at bellsouth.net>
>>> Date: Thu, 11 Nov 2004 8:44:09 -0500
>>> To: <carter at qosient.com>
>>> Cc: <argus-info at lists.andrew.cmu.edu>
>>> Subject: 2.0.6.fixes.1 core from improper signal handling
>>> 
>>> 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
>>> 
>> 
>> 
>> 
> 
>