[lkml]   [2002]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.20-aa and LARGE Squid process -> SIGSEGV
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

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

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


At 08:52 AM 21/12/2002 +0100, Ralf Hildebrandt wrote:
>* J.A. Magallon <>:
> > 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)
>Charite Campus Mitte Tel. +49 (0)30-450 570-155
>Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
>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
>More majordomo info at
>Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:31    [W:0.056 / U:20.868 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site