Re: [SQU] assertion failed: pump.c:373 in 2.3-STABLE4

Hi Henrik,

    Using gdb to get the backtrace, it seems that something its missing, to
make this work correctly, do I have to install a stripped squid binary or
something like that, if yes how can I do that???, or what do I need to get
the backtrace correctly???

gdb /usr/local/sbin/squid
(gdb) r -CNd1
...
...
...
A few seconds
...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGPIPE, Broken pipe.
0x48186440 in write () from /usr/lib/libc.so.4
(gdb) bt
#0 0x48186440 in write () from /usr/lib/libc.so.4
#1 0x8064128 in getsockname ()
#2 0x806535c in getsockname ()
#3 0x80873de in getsockname ()
#4 0x804a33d in getsockname ()

Thanks
Ales

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Alejandro A. Ramirez" <ales@megared.net.mx>
Cc: <squid-users@ircache.net>
Sent: Monday, January 22, 2001 7:31 PM
Subject: Re: [SQU] assertion failed: pump.c:373 in 2.3-STABLE4

> Alejandro A. Ramirez wrote:
> >
> > Actually it seems that I have hit a bug in 2.3-STABLE4, , I have 3 Cisco
> > Cache Engines, an 1 Squid with FreeBSD 4.1-RELEASE 1GB RAM 2 PIII
600Mhz,
> > when I turned off all the CCE´s, it went up to 248 req/s and it gave
this
> > error in the cache.log file:
> >
> > 2001/01/22 10:26:38| clientSendMoreData: Deferring
> > error:invalid-request
> > 2001/01/22 10:26:38| assertion failed: pump.c:373:
> > "!fd_table[p->s_fd].flags.open"
>
> Any chance you could get a stack trace from that one? Would help a lot
> to pinpoint the problem..
>
> But my first guess is yet another problem with pipelined requests. I do
> not yet trust the way Squid manages pipelinig, and always disable it on
> production systems by changing one line in client_side.c:
>
> from
> if (nrequests >= 2) {
> to
> if (nrequests >= 1) {
>
> --
> Henrik Nordstrom
> Squid hacker
>
> --
> To unsubscribe, see http://www.squid-cache.org/mailing-lists.html

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html