Re: assertion failed: ipcache.cc:995: "tmpbuf" in 3.HEAD-CVS

From: Amos Jeffries <squid3@dont-contact.us>
Date: Wed, 09 Jan 2008 11:41:50 +1300

Henrik Nordström wrote:
> tis 2008-01-08 klockan 13:53 +0100 skrev Bernhard Schmidt:
>> Hi,
>>
>> I've been running Squid 3.0-ipv6 branch and now 3.HEAD for quite some
>> time and found that after an upgrade my Squid cache was wildly crashing
>> with
>>
>> assertion failed: ipcache.cc:995: "tmpbuf"
>
> This is related to recursive processing of CNAME DNS responses recently
> added to Squid-3 in December.
>
> I wonder.. do we really need to recursively resolve CNAME response? We
> sent an A / AAAA query, and all resolveds I know of do the recursion and
> include the answer from start.
>
> Has worked forever for Squid-2 without recursing into cname responses.

It has worked for A records because the trend there has been for people
to use A records commonly. These days of AAAA records and long-IP have
seen a major increase in CNAME records pointing at shared AAAA instead
of multiple individual AAAA.

When I was fixing it, I found a large number of those 'cannot connect to
X website' errors last year with A records was because that website used
CNAME redirection and the user was doing internal DNS.

The short of it is that without CNAME resolution either directly or via
the external-DNS helper a very large proportion of usable AAAA records
show up as false-failures.

The assert problem is a case of why the cached list of IPA has a pointer
one line and NULL a few later!

Bernhard:
  Can you get a cache.log trace of section 14 please?

  On a wacky side-thought: does changing the assert to (tmpbuf != NULL)
fix it for you?

Amos

-- 
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.
Received on Tue Jan 08 2008 - 15:41:43 MST

This archive was generated by hypermail pre-2.1.9 : Wed Jan 30 2008 - 12:00:09 MST