Re: [squid-users] Hunting SegFaults

On Tuesday 14 May 2002 06:49, Brian wrote:

> There are two basic problems here:
> 1. It died.
> 2. Somewhere after 262144 objects, it stopped and it took a kill
> -9 to make it exit.

Next time, before killing it try to get a stacktrace showing what it
is upto..

  gdb /path/to/squid `cat squid.pid`
  backtrace
  quit

> The front-line servers also die occasionally, but they come back.
> They're smaller (70,000 objects), so perhaps the item count plays a
> role in problem 2?

Should not.. but sure, the more items you have, the more data there
is, and perhaps the higher risk that if something gets corrupted then
it will hit something.. (the reverse may also be true, depends on the
nature of the corruption)

> This squid also has
> quick_abort_min -1 KB
> range_offset_limit -1 bytes
>
> while the front-line doesn't. This means it often retrieves cache
> misses at LAN speed. At one point, I also had READ_AHEAD_GAP set
> to 2MB, but that makes it downright unstable (crashing about once a
> week).

There might be a hint on what is going on.. I am not sure how well
tested the code for continuing retreival after the last client is
gone is..

> How do I find out what's going on here? Since it continues past
> the segfault, would a core dump work? If so, how do you create/use
> a multi-thread dump?

A coredump would work, but it can be somewhat tricky to make a
pthreads enabled application to coredump. See the Squid FAQ for a
couple of alternatives. Especially on such low frequency problems
which is hard to intentionally repeat..

If everything fails, --enable-stacktraces (or using catchsegv and
starting Squid with the -C option) will give you at least a
rudimentary backtrace.

-- 
MARA Systems AB, Giving you basic free Squid support
Your source of advanced web reverse proxying solutions
http://www.marasystems.com/products/