[reSIProcate] Assertion failure in ares_p rocess.c

[Kennard White]

Hi Xmly,

Makes sense, thanks for tracing this down and fixing. I'll commit this
change sometime next week after Scott completes a branch merge.

Thanks,
Kennard

2011/2/23 ximalaya <ims3g at 126.com>

> Hi Kennard,
> Nice to have you to look into this problem.
> Epoll was not enabled in my buid. I updated the code and rebuit, assertion
> failure is still there at the same place.
> While according to the information you provided, I think I've found some
> clues. Ares may try different ways to get the name servers, in my case,
> init_by_defaults(in file ares_init.c) was also tried as the last option. The
> issue is just caused by this function.
>
> ares_init.c, lines starting from line 601
>         /* If nobody specified servers, try a local named. */
>         channel->servers = malloc(sizeof(struct server_state));
>         if (!channel->servers)
>             return ARES_ENOMEM;
>         memset(channel->servers, '\0', sizeof(struct server_state));
>
>         // need a way to test here if v4 or v6 is running
>         // if v4 is running...
>         channel->servers[0].addr.s_addr = htonl(INADDR_LOOPBACK);
>         channel->servers[0].default_localhost_server = 1;
>
> The address family is set to zero.  Following lines can be added after line
> 605,
> #ifdef USE_IPV6
>     channel->servers[0].family = AF_INET;
> #endif
>
> Thanks and Best Regards,
> Xmly
>
>
> At 2011-02-22 12:00:51，"Kennard White" <kennard_white at logitech.com> wrote:
>
> HI Xmly,
>
> I inspected the code and couldn't find an initialization problem; see
> rutil/dns/AresDns.cxx around line 274. However, I added an additional assert
> into ares_init() that should detected this problem at init time rather than
> time of lookup.
>
> The most likely cause is a mismatch between how ares and rutil was built.
> Note that rutil will detect if it is built with IPV6 and ares is without,
> but the reverse isn't true: if rutil is built without IPV6 and ares with,
> then program will attempt to run (see AresDns around line 214).  In this
> case you should have receive a Warning log message: "Ignoring non-IPv4
> additional name server". Unfortunately, I don't think it is actually
> ignored, but rather it passes zero data in that might cause this assertion.
>
> I've had issues under Linux with switching the build options of
> contrib/ares; I always run "make clean-ares" at the top to force a rebuild.
>
> Can you checkout the latest SVN (to pick up the new assertion) and build
> from scratch? If it still happens, can you provide more information about
> your platform, configuration, application and timing?
>
> Scott,
> I checked the diff's, and while I collapsed some code, I'm pretty sure no
> behavior changes. The ABI dependency of ares on USE_IPV6 is nasty; when I
> find time I might try using the union w/padding trick of GenericIPAdress to
> to remove this dependency from ares_init().
>
> Regards,
> Kennard
>
> 2011/2/19 ximalaya <ims3g at 126.com>
>
>> Hi,
>>
>>  I encountered ares assertion failure today. Details please see below
>> trace log.
>> The repro server was build with IPv6 enabled and resip-ares using latest
>> svn codes.
>> INFO | 20110219-182105.421 | repro | REPRO:APP | 0x100b2ef8 |
>> ResponseContext.cx
>> x:279 | Creating new client transaction c8612e4c96f38c1a ->
>> sip:user at xx.org
>> assertion "family == AF_INET || family == AF_INET6" failed: file
>> "../ares/ares_p
>> rocess.c", line 776, function: open_udp_socket
>>
>> After checking the code, I find the failure is here, can someone check the
>> address family field is initialized properly?
>> static int open_udp_socket(ares_channel channel, struct server_state
>> *server) {
>>
>> #ifdef USE_IPV6
>>   family = server->family;
>>   assert(family == AF_INET || family == AF_INET6); //line 776
>> #else
>>   family = AF_INET;
>> #endif
>> …
>> }
>>
>> Thanks,
>> Xmly
>>
>>
>>
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110223/9ac117a1/attachment.htm>