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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
