< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Bug in ares


I also met with same problem after upgrade to Release 1.2, previous version seems ok.

It happens when launching repro under condition that /etc/resolv.conf has more than 2 name servers on Linux.
I wondered it was caused by alignment issue.
 
After change line
memset(newserv + (*nservers * sizeof(struct server_state)), '\0', sizeof(struct server_state));
to
memset(&newserv[*nservers], '\0', sizeof(struct server_state));
 
The coredump seemed gone.
 
 
 
 
 

2008-01-11,"Johannes Dohmen" <johannes.dohmen@xxxxxx> :
Hi there,

sorry for the following prose. I was not able to explain myself in 
shorter terms.

Lately I'm getting strange errors in my sip-app. With strange I mean 
SIGSEGFAULT or SIGABORT from various location in my app, resip or some 
system-libs, depending on how I arrange the function-calls in my main. I 
tried to debug my code, but did not find any errors. Today I started my 
app in gdb with electric fence enabled and it crashed in the ares-lib (I 
needed to compile it with no optimization):

ares_init.c:713:
memset(newserv + (*nservers * sizeof(struct server_state)), '\0', 
sizeof(struct server_state));   // clear *new* memory only

although I don't see the error (I inspected the values in gdb they seem 
ok to me). Removing the line fixes the issue for me but I wondered if I 
fixed the bug or just hid it.
I looked for the website of ares to find out that the lib is 
discontinued since 2001. Instead I found a fork of ares named c-ares 
(http://daniel.haxx.se/projects/c-ares/) which source I checked for the 
memset in question just to discover that the line is removed from this 
project as well.
All in all I'm quite convinced that the memset in ares is buggy.

I was not yet able to make a simple test to trigger the error and cannot 
post my app as it is partly closed source...

Please let me know what you think about the case, thank you.

Despite from the bug, shouldn't maybe a switch to the c-ares library be 
considered?

Greetings
Johannes Dohmen

Fyi:
Os: Debian amd64/sid; Debian i386/stable

Compiler: gcc/g++4.2.3: gcc/g++-4.1

resolv.conf:
nameserver 192.168.101.1
nameserver 192.168.1.1
search sub.example.com

The bug occurs when configuring the 2nd nameserver....

Bt (one of many differents as I stated above):
#0  0x00002aad8ca81fd5 in raise () from /lib/libc.so.6
#1  0x00002aad8ca83a30 in abort () from /lib/libc.so.6
#2  0x00002aad8cabca3b in ?? () from /lib/libc.so.6
#3  0x00002aad8cac3fca in ?? () from /lib/libc.so.6
#4  0x00002aad8cac7b5c in free () from /lib/libc.so.6
#5  0x00002aad8dd0696d in CRYPTO_free () from /usr/lib/libcrypto.so.0.9.8
#6  0x00002aad8dd64906 in EVP_MD_CTX_cleanup () from /usr/lib/libcrypto.so.0.9.8
#7  0x00002aad8dd60a46 in ?? () from /usr/lib/libcrypto.so.0.9.8
#8  0x00002aad8acf6cbf in resip::Random::initialize () at Random.cxx:136
#9  0x00002aad8a971f39 in SipStack (this=0x7fff20970de0, pSecurity=0x0, additional=@0x696ac0, handler=0x0, stateless=false, socketFunc=0, 
compression=0x0) at SipStack.cxx:71
#10 0x0000000000430939 in UserAgent (this=0x7fff20970030, sUser=@0x7fff209b9640, sPass=@0x7fff209b9630, sServer=@0x7fff209b9e50, 
sPort=@0x7fff209b95f0,    sRtpListenPort=@0x7fff209b95e0, sRtpSendPort=@0x7fff209b95d0, 
sUaName=@0x7fff209b9e40) at src/UserAgent.cpp:34
#11 0x0000000000450297 in main (argc=5, argv=0x7fff209ba218)

Bt with electric fence:
#0  0x00002b700fe27270 in memset () from /lib/libc.so.6
#1  0x0000000000422d9a in config_nameserver (servers=0x7fff9d615b28, nservers=0x7fff9d615b38, str=0x2b701ae20f8b "192.168.1.1") at 
../ares/ares_init.c:713
#2  0x0000000000422819 in init_by_resolv_conf (channel=0x2b701ae1cfa0) at ../ares/ares_init.c:351
#3  0x000000000042215d in ares_init_options_with_socket_function (channelptr=0x2b701ae1aff8, options=0x7fff9d615e50, optmask=0, 
socketFunc=0) at ../ares/ares_init.c:166
#4  0x00002b700e058104 in resip::AresDns::init (this=0x2b701ae1aff0, additionalNameservers=@0x6976a0, socketfunc=0, timeout=0, tries=0, 
features=0) at dns/AresDns.cxx:63
#5  0x00002b700e061c3a in DnsStub (this=0x2b701ae14ed0, additional=@0x6976a0, socketFunc=0) at dns/DnsStub.cxx:81
#6  0x00002b700dcccd03 in SipStack (this=0x7fff9d617a50, pSecurity=0x0, additional=@0x6976a0, handler=0x0, stateless=false, socketFunc=0, 
compression=0x0) at SipStack.cxx:68
#7  0x0000000000431129 in UserAgent (this=0x7fff9d616ca0, sUser=@0x7fff9d6602b0, sPass=@0x7fff9d6602a0, sServer=@0x7fff9d660ac0, 
sPort=@0x7fff9d660260, sRtpListenPort=@0x7fff9d660250, sRtpSendPort=@0x7fff9d660240, 
sUaName=@0x7fff9d660ab0) at src/UserAgent.cpp:34
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel