Subject: Re: What is the correct way of integrating c-ares in a separate project

Re: What is the correct way of integrating c-ares in a separate project

From: David Hotham via c-ares <c-ares_at_cool.haxx.se>
Date: Tue, 1 Aug 2017 08:54:32 +0100

Unclear without the full program, but perhaps this is a locking issue.
If you have:

- one thread on which you're looping round calling rec_c_ares_execute()

- another on which you're making queries

... then the c-ares channel should be protected by a mutex when making
calls into c-ares.

David

-

On 01/08/2017 08:34, daniel_at_poradnik-webmastera.com wrote:
> W dniu 2017-07-31 14:19, Gisle Vanem via c-ares napisaƂ(a):
>> Austin Einter wrote:
>>
>>> By referring some online help, I have integrated it. However it is
>>> working till sometime, after that it is crashing.
>>> The stack trace is shown as above.
>>>
>>> /(gdb) bt/
>>> /#0 0x00007f959c01ac37 in __GI_raise (sig=sig_at_entry=6) at
>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56/
>>> /#1 0x00007f959c01e028 in __GI_abort () at abort.c:89/
>>> /#2 0x00007f959c0572a4 in __libc_message
>>> (do_abort=do_abort_at_entry=2, fmt=fmt_at_entry=0x7f959c166d70 "*** %s
>>> ***: %s terminated\n")/
>>> / at ../sysdeps/posix/libc_fatal.c:175/
>>> /#3 0x00007f959c0f283c in __GI___fortify_fail (msg=<optimized out>,
>>> msg_at_entry=0x7f959c166d07 "buffer overflow detected") at
>>> fortify_fail.c:38/
>>> /#4 0x00007f959c0f1710 in __GI___chk_fail () at chk_fail.c:28/
>>> /#5 0x00007f959c0f2787 in __fdelt_chk (d=<optimized out>) at
>>> fdelt_chk.c:25/
>>> /#6 0x00007f959c6b69ad in ares_fds () from
>>> /usr/local/multiplier/system/libs/libcares.so.2/
>>> /#7 0x000000000040b448 in rec_c_ares_execute () at
>>> /home/necs/dev/apat/source/recorder/recdns.c:157/
>>> /#8 0x00000000004052f2 in rec_main_thread (data=0x0) at
>>> /home/necs/dev/apat/source/recorder/rec.c:772/
>>> /#9 0x0000000000403de1 in main (argc=7, argv=0x7fff58cde398) at
>>> /home/necs/dev/apat/source/recorder/main.c:129/
>> ...
>>
>>> bool rec_c_ares_init()
>>> {
>>> int status;
>>> int optmask = 0;
>>> struct ares_options options;
>>
>> Try making this:
>> static struct ares_options options;
>>
>> --
>> --gv
>
> You are either crossing FD_SETSIZE limit, or have negative number of
> fds. Glibc checks this internally and causes crash if check will fail:
> https://github.com/lattera/glibc/blob/master/debug/fdelt_chk.c
>
> Daniel
Received on 2017-08-01