Re: Is it really necessary for fatal() to dump core?

Yeah; looking through, it looks to me like a few in the auth and fs
modules need to be changed to fatal_dump; the rest (over a hundred)
don't really need a core -- they're things like config parsing errors
and self-evident error states.

I'll come up with a patch that does that and adds a FATAL_DUMPS
compile-time flag with a 0 default.

On 20/05/2009, at 11:28 AM, Mark Nottingham wrote:

> The case that triggered this for me was when the log daemon dies;
> doesn't make much sense to core there either.
>
> I'll take a look through and report back.
>
>
> On 20/05/2009, at 11:24 AM, Amos Jeffries wrote:
>
>>> I'm going to push back on that; the administrator doesn't really
>>> have
>>> any need to get a core when, for example, append_domain doesn't
>>> start
>>> with .'.
>>>
>>> Squid.conf is bloated as it is; if there are cases where a core
>>> could
>>> be conceivably useful, they should be converted to fatal_dump. From
>>> what I've seen they'll be a small minority at best...
>>>
>>
>> That I agree with. Grep the code for all fatals and see what falls
>> out.
>> I think you will find it's only the config parser that can get away
>> with
>> non-core fatals.
>>
>> Amos
>>
>>>
>>>
>>>
>>> On 19/05/2009, at 2:25 PM, Adrian Chadd wrote:
>>>
>>>> just make that behaviour configurable?
>>>>
>>>> core_on_fatal {on|off}
>>>>
>>>>
>>>>
>>>> Adrian
>>>>
>>>> 2009/5/19 Mark Nottingham <mnot_at_yahoo-inc.com>:
>>>>> tools.c:fatal() dumps core because it calls abort.
>>>>>
>>>>> Considering that the core can be quite large (esp. on a 64bit
>>>>> system), and
>>>>> that there's fatal_dump() as well if you really want one, can we
>>>>> just make
>>>>> fatal() exit(1) instead of abort()ing?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> Mark Nottingham mnot_at_yahoo-inc.com
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Mark Nottingham mnot_at_yahoo-inc.com
>>>
>>>
>>>
>>
>>
>
> --
> Mark Nottingham mnot_at_yahoo-inc.com
>
>

--
Mark Nottingham       mnot_at_yahoo-inc.com