[squid-users] Survey on assertions: When the impossible happens

[Alex Rousskov]

On 02/29/2016 10:22 AM, Marcus Kool wrote:
> 
>> * Choices.
>>
>> Overall, there are three options for handling an impossible situation:
>>
>> 1. Quit Squid process. This is what Squid does today in most cases.
>>     When the impossible happens, you get a crash. Very predictable.
>>     No malformed/corrupted/misleading HTTP messages (some are truncated).
>>     No memory leaks.
>>
>> 2. Quit the current processing sequence but keep Squid process running,
>>     assuming that [most] other processing sequences are not affected.
>>     [If you are familiar with programming, this is done by throwing
>>     exceptions instead of asserting and catching those exceptions at
>>     "processing sequence" boundaries].
>>
>> 3. Keep executing the current processing sequence, assuming that the
>>     assertion was wrong or unimportant. This is what you might be
>>     suggesting above. When the impossible happens, you may get a crash,
>>     memory leaks, malformed/corrupted/misleading HTTP messages, or normal
>>     behavior, depending on the assertion and traffic.
>>
>> IMO, we should make #2 the default, but make the choice between all
>> three options configurable by the admin (without recompiling Squid).


> Let me suggest #4 :
> 
> immediately execute an external program that calls gdb or any other
> debugger
> which produces a stack trace of all squid processes and then do #1 or #2.

This is not really #4. It is an enhancement for any of the three
options. IIRC, Squid even supported gdb stack tracing natively on some
platforms (but a script would arguably be better, except for busy
proxies that cannot be blocked for 2-4 seconds it takes to run that script).


> The stack dumps will be save in an assertion failure log file which admins
> can send to Squid developers.
> 
> This will speedup the debugging and fixing procedure.

Agreed.


Thank you,

Alex.