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: Austin Einter via c-ares <c-ares_at_cool.haxx.se>
Date: Tue, 1 Aug 2017 15:28:06 +0530

Hi David,
Thanks for kind reply.

Mine is single threaded system. From main while loop I keep calling
rec_c_ares_execute().
As part of that execution, probably callbacks are called. When c-ares calls
my callback, I post an event to my thread to make sure I avoid nested
calling.

Also while making queries, I hope c-ares would not call callback. Even if
it calls callback, not an issue, as I break from execution path with just
event posting.

Best Regards
Kamal

On Tue, Aug 1, 2017 at 1:24 PM, David Hotham via c-ares <c-ares_at_cool.haxx.se
> wrote:

> 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