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 08:45:06 +0530

I am convinced its c-ares issue. I used tadns instead of c-ares for async
dns lookup. I see this issue is gone. Most likely its a stack overflow
issue.

Is it a known issue?

Do I need to file a bug some where..

On Mon, Jul 31, 2017 at 8:14 PM, Austin Einter <austin.einter_at_gmail.com>
wrote:

> Dear Gisle Vanem
> Tried with "static struct ares_options options;".
> Same error, this dumps on terminal.
>
> *** buffer overflow detected ***: ./recorder terminated
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7f35be7c829f]
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f35be86383c]
> /lib/x86_64-linux-gnu/libc.so.6(+0x10d710)[0x7f35be862710]
> /lib/x86_64-linux-gnu/libc.so.6(+0x10e787)[0x7f35be863787]
> /usr/local/multiplier/system/libs/libcares.so.2(ares_fds+
> 0x6d)[0x7f35bee279ad]
> ./recorder[0x40b2f4]
> ./recorder[0x405340]
> ./recorder[0x403dd6]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f35be776f45]
> ./recorder[0x403bf9]
> ======= Memory map: ========
> 00400000-00442000 r-xp 00000000 08:07 3696653
> /home/necs/dev/apat/source/workspace/apat/recorder/recorder
> 00642000-00643000 r--p 00042000 08:07 3696653
> /home/necs/dev/apat/source/workspace/apat/recorder/recorder
> 00643000-00646000 rw-p 00043000 08:07 3696653
> /home/necs/dev/apat/source/workspace/apat/recorder/recorder
> 01ce0000-031c1000 rw-p 00000000 00:00 0
> [heap]
>
>
> On Mon, Jul 31, 2017 at 5:49 PM, Gisle Vanem via c-ares <
> c-ares_at_cool.haxx.se> wrote:
>
>> 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
>>
>
>
Received on 2017-08-01