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

Henrik Nordström wrote:
> tor 2008-01-10 klockan 20:40 +1300 skrev Amos Jeffries:
>
>> Doh! thanks. I think I see the problem, its should be checking tmpbuf is
>> NULL when no records are present, non-NULL when they are.
>> The assert was there to stop the safe free dying nastily. If it's
>> working for you better without great. I'll commit the fix to HEAD shortly.
>
> safe_free happily accepts NULLs.. hence the name safe_...

I forget exactly why it was there. Likely a crash when it was non-NULL
when it should have been NULL. Fixed now anyway.

>
>> BTW Henrik: You see the case for CNAMEs now? That lookup is a pretty
>> clear example.
>
> That lookup is an exact case of what I have been saying all time along.
> If an AAAA query do not return an AAAA record (only CNAME or other stuff
> not asked for) you must fall back on an A query, just the same as if no
> records at all was returned.

Aha, I sees' 'ze bugs.

query 1: AAAA
response: CNAME + NX additional
result: was returns no-results shortcut in DNS.
(identical if A returns CNAME-only)

query 2: AAAA
response: NX or ip + anything
result: failover to A

query 3: A
response: NX or ip + anything
result: return answers for A.

Without the recursion 1 results in neg-cache. With it enabled the
recursion skips the bug and failover results in 2 & 3 running on the
recursed lookup to hit bug #2 (no AAAA ever returned, but connection
goes through).

>
> So, no, I don't see the case for needing to manually recurse CNAMEs. The
> name server resolver already does that for you, don't try to outguess
> the resolver.
>
> Regards
> Henrik

Amos

-- 
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.