Re: 2.4.20-aa and LARGE Squid process -> SIGSEGV

[Reuben Farrelly]

No, squid is not br0ken in this fashion.  If squid cannot be allocated 
enough memory by the system, it logs a message and _dies_.  Relevant files 
to look at in your squid source are squid/lib/util.c for xcalloc() and 
xmalloc().

Aside from this, if squid ever does get to the point of swapping, it is 
misconfigured and your performance has just gone to hell anyway...  (see 
the FAQ at www.squid-cache.org)

Questions relating to squid performance and stability should really be 
discussed on the squid users mailing list, you can find details on this 
list at http://www.squid-cache.org/mailing-lists.html

Reuben

At 08:52 AM 21/12/2002 +0100, Ralf Hildebrandt wrote:
>* J.A. Magallon <[e-mail]>:
>
> > For user space memory, there is no real OOM state. The system (glibc) just
> > does not give you the memory, returns NULL in the malloc, and it is your
> > responsibility to check malloc's return value. If you do not check it,
> > you try to access a null pointer and _bang_. So in your case, after enough
> > iterations on malloc() without free(), it returns NULL and you fall into
> > a null pointer dereference.
>
>Ergo: Squid is br0ken.
>
>--
>Ralf Hildebrandt (Im Auftrag des Referat V a)   [e-mail]
>Charite Campus Mitte                            Tel.  [phone]
>Referat V a - Kommunikationsnetze -             Fax.  [phone]
>Windows is the answer, but only if the question was 'what is the
>intellectual equivalent of being a galley slave?'
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [e-mail]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/