Re: [reSIProcate] Crash inside RRList::update()
Hi all.
One important detail -- I compile reSIProcate with IPv6 support
disabled.
I looked a bit through the code (up-to-date), and my guess is AAAA DNS
records cause the crash.
I found that T_AAAA definition is protected with '#ifdef USE_IPV6' in
one place (rutil/dns/RRCache.cxx:62), but it is not in many others.
Presumably, this causes RRCache::updateCache() to pass
mFactoryMap.end()->second to RRList constructor, since
^^^
(it != mFactoryMap.end()) assertion is missing in release builds.
So, the question is what would be the right fix(es):
1) Change assert(it != mFactoryMap.end()) to
if (it != mFactoryMap.end()) { ... }
> This particular problem will be fixed, but is there guarantee that
there are no others?
2) Protect T_AAAA with '#ifdef USE_IPV6' inside
DnsStub::supportedType()
> Will this cover all problem cases?
3) Protect T_AAAA with '#ifdef USE_IPV6' everywhere.
> Is this acceptable?
4) Remove '#ifdef USE_IPV6' protection from RRCache.cxx:62.
> Wouldn't it affect other pieces of code that are not aware of IPv6?
I personally will try (1)+(2) in my local code base so far.
On Fri, 27 Jan 2006, Dmitry Semyonov wrote:
> Environment: reSIProcate rev.5685 on Win2K.
> (The revision is rather old, but looks like there were no changes in
> the DNS code that might have fixed the issue in later revisions.)
>
> In some rare yet undetermined cases I encounter crash inside DNS
> code:
>
> > resip::RRList::update() Line 62 + 0x3
> resip::RRList::RRList() Line 50
> resip::RRCache::updateCache() Line 95 + 0x41
> ___WSAFDIsSet@8() + 0x9544
> resip::DnsStub::Query::followCname() Line 487 + 0x30
>
> Exact place is highlighted below (ECX is zero):
>
> 62: item.record = factory->create(*it);
> 01B4F439 mov ecx,dword ptr [ebp+8]
> > 01B4F43C mov eax,dword ptr [ecx]
> 01B4F43E push edi
> 01B4F43F mov byte ptr [ebp-4],1
> 01B4F443 call dword ptr [eax+4]
>
> Adding sanity pointer checks will likely solve the issue, but will
> it be the right solution?
>
> Could anybody familiar with DNS code review the trace, and possibly
> propose a better fix?
--
...Bye..Dmitry.