Re: [reSIProcate] Assertion failure in ares_p rocess.c

[Kennard White <kennard_white@xxxxxxxxxxxx>]

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@xxxxxxx>

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@xxxxxxxxxxxx> 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@xxxxxxx>

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@xxxxxx
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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel