<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br> <BR><div>> Date: Sat, 22 Jun 2013 11:32:04 -0500<br>> From: krice@freeswitch.org<br>> To: freeswitch-users@lists.freeswitch.org; freeswitch-dev@lists.freeswitch.org<br>> Subject: Re: [Freeswitch-dev] [Freeswitch-users] origin/master's HEAD is segfaulting<br>> <br>> Oh come on people... Jira... That's where you report bugs... And yes a<br>> segfault is a bug<br>> </div><div> </div><div>I guess I should not my rant against "jira" :).</div><div> </div><div>I will post it there with further info. In between, same thing happens for 1.5.whateverlatest</div><div>tag. Which left me a little surprised.</div><div><br>> <br>> On 6/22/13 9:03 AM, "arif hossain" <aftnix@live.com> wrote:<br>> <br>> > Hi,<br>> > <br>> > I'm on this commit :<br>> > arif@khost:~/src/freeswitch$ git show HEAD<br>> > commit f8122e39c51240b99bf07a767afe2f8a698f1486<br>> > <br>> > Now its segfaulting on startup.<br>> > <br>> >> From generated core :<br>> > <br>> > Program terminated with signal 11, Segmentation fault.<br>> > #0 0x00007f245cc28df1 in su_casematch (s1=0x7f245cc7fc57 "",<br>> > s2=0x3000000030 <Address 0x3000000030 out of bounds>) at su_string.c:224<br>> > 224 unsigned char a = *s1++, b = *s2++;<br>> > <br>> > Clearly s2 is wrongly initialized.<br>> > <br>> > The backtrace :<br>> > <br>> > (gdb) bt<br>> > #0 0x00007f245cc28df1 in su_casematch (s1=0x7f245cc7fc57 "",<br>> > s2=0x3000000030 <Address 0x3000000030 out of bounds>) at su_string.c:224<br>> > #1 0x00007f245cc377ff in tport_server_addrinfo (mr=0x7f243c003c30,<br>> > canon=0x7f243c003bfe "[::1]", family=0, host=0x7f245c958670 "::1",<br>> > service=0x7f243c003c04 "5060", protocol=0x7f245cc7fc56 "*",<br>> > transports=0x7f245c9589c0, return_addrinfo=0x7f245c958608) at tport.c:1814<br>> > #2 0x00007f245cc370a1 in tport_bind_server (mr=0x7f243c003c30,<br>> > tpn=0x7f245c958770, transports=0x7f245c9589c0, public=tport_type_local,<br>> > tags=0x7f245c958730) at tport.c:1652<br>> > #3 0x00007f245cc36762 in tport_tbind (self=0x7f243c003c30,<br>> > tpn=0x7f245c958a50, transports=0x7f245c9589c0,<br>> > tag=0x7f245cecae20 <tptag_ident>, value=139794152182707) at tport.c:1524<br>> > #4 0x00007f245cb8882d in nta_agent_add_tport (self=0x7f243c001e40,<br>> > uri=0x7f24400099c0, tag=0x7f245cecae20 <tptag_ident>,<br>> > value=139794152182707) at nta.c:2237<br>> > #5 0x00007f245cbc4e71 in nua_stack_init_transport (nua=0x7f2440007970,<br>> > tags=0x7f24400098f0) at nua_register.c:1216<br>> > #6 0x00007f245cbd6b6b in nua_stack_init (root=0x7f243c001130,<br>> > nua=0x7f2440007970) at nua_stack.c:194<br>> > #7 0x00007f245cc24441 in su_pthread_port_clone_main (varg=0x7f245c9d03d0)<br>> > at su_pthread_port.c:340<br>> > #8 0x00007f2460ffae9a in start_thread ()<br>> > from /lib/x86_64-linux-gnu/libpthread.so.0<br>> > ---Type <return> to continue, or q <return> to quit---<br>> > #9 0x00007f2460d27ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6<br>> > #10 0x0000000000000000 in ?? ()<br>> > <br>> > <br>> > In tport_server_addrinfo() :<br>> > <br>> > (gdb) list tport_server_addrinfo<br>> > ...<br>> > 1800 char const * const transports[],<br>> > ...<br>> > ...<br>> > 1811 for (i = 0, N = 0; transports[i] && N < TPORT_N; i++) {<br>> > 1812 su_addrinfo_t *ai = &hints[N];<br>> > 1813 <br>> > 1814 if (!su_casematch(protocol, transports[i]) &&<br>> > !su_strmatch(protocol, "*"))<br>> > <br>> > So char const * const transports[] is not correctly initialized before using<br>> > its values in the for loop.<br>> > <br>> > (gdb) p transports[0]<br>> > $3 = 0x3000000030 <Address 0x3000000030 out of bounds><br>> > (gdb) p transports[1]<br>> > $4 = 0x7f245c958d00 "`\215\225\\$\177"<br>> > <br>> > So transports[0] is the problematic initialization here.<br>> > <br>> > Going back further, in libs/sofia-sip/libsofia-sip-ua/nta/nta.c: 2150<br>> > <br>> > char const * const * tports = tports_sip;<br>> > <br>> > And here<br>> > <br>> > (gdb) ptype tports_sip<br>> > type = const char * const[5]<br>> > (gdb) p tports_sip[0]<br>> > $6 = 0x7f245cc7fc38 "udp"<br>> > (gdb) p tports[0]<br>> > $7 = 0x3000000030 <Address 0x3000000030 out of bounds><br>> > (gdb) ptype tports_sip<br>> > type = const char * const[5]<br>> > (gdb) p tports<br>> > $11 = (const char * const *) 0x7f245c9589c0<br>> > (gdb) p &tports_sip<br>> > $12 = (const char * const(*)[5]) 0x7f245cebf660 <tports_sip><br>> > <br>> > As it can be seen, tports diverged from initial tports_sip.<br>> > It has been done in following snippet :<br>> > <br>> > 2197 if (strchr(tp, ',')) {<br>> > 2198 int i; char *t, *tps[9] = {0};<br>> > 2199<br>> > 2200 /* Split tp into transports */<br>> > 2201 for (i = 0, t = tp; t && i < 8; i++) {<br>> > 2202 tps[i] = t;<br>> > 2203 if ((t = strchr(t, ',')))<br>> > 2204 *t++ = '\0';<br>> > 2205 }<br>> > 2206<br>> > 2207 tps[i] = NULL;<br>> > 2208 tports = (char const * const *)tps;<br>> > <br>> > <br>> > Now :<br>> > <br>> > (gdb) p tp<br>> > $20 = "udp\000tcp\000H\215\225\\$\177\000\000\240\252\354\\"..<br>> > <br>> > So above code should parse "udp" in tports[0]. Which is not the case here.<br>> > <br>> > I'm assuming this bug has to generated from a more higher level, rather than<br>> > happened in a file which has not been touched since 2006( I git blamed it).<br>> > <br>> > But bt does not have any calls to "non-sofia" stuff.<br>> > <br>> > This su_casematch() was called from two threads,<br>> > <br>> > 4 Thread 0x7f245eccb700 (LWP 7622) 0x00007f245cc28df1 in su_casematch (<br>> > s1=0x7f245cc7fc57 "", s2=0x3000000030 <Address 0x3000000030 out of<br>> > bounds>)<br>> > at su_string.c:224<br>> > <br>> > * 1 Thread 0x7f245c959700 (LWP 7623) 0x00007f245cc28df1 in su_casematch (<br>> > s1=0x7f245cc7fc57 "", s2=0x3000000030 <Address 0x3000000030 out of<br>> > bounds>)<br>> > at su_string.c:224<br>> > <br>> > <br>> > Both calls to su_casematch seems problematic.<br>> > <br>> > Sorry for a long BUGREPORT. Actually i thought i should post my investigation<br>> > if it helps the devs(After git blaming, i highly suspect that my investigation<br>> > unearthed nothing , problem generated from elsewhere, which i could not find).<br>> > <br>> > I've not started git bisecting. If it helps, i will be happy to do that.<br>> > <br>> > <br>> > <br>> > <br>> > <br>> > -- <br>> > Cheers<br>> > arif <br>> > _________________________________________________________________________<br>> > Professional FreeSWITCH Consulting Services:<br>> > consulting@freeswitch.org<br>> > http://www.freeswitchsolutions.com<br>> > <br>> > FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>> > http://www.cudatel.com<br>> > <br>> > Official FreeSWITCH Sites<br>> > http://www.freeswitch.org<br>> > http://wiki.freeswitch.org<br>> > http://www.cluecon.com<br>> > <br>> > FreeSWITCH-users mailing list<br>> > FreeSWITCH-users@lists.freeswitch.org<br>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>> > http://www.freeswitch.org<br>> <br>> -- <br>> Ken<br>> http://www.FreeSWITCH.org<br>> http://www.ClueCon.com<br>> http://www.OSTAG.org<br>> irc.freenode.net #freeswitch<br>> <br>> <br>> <br>> _________________________________________________________________________<br>> Professional FreeSWITCH Consulting Services:<br>> consulting@freeswitch.org<br>> http://www.freeswitchsolutions.com<br>> <br>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>> http://www.cudatel.com<br>> <br>> Official FreeSWITCH Sites<br>> http://www.freeswitch.org<br>> http://wiki.freeswitch.org<br>> http://www.cluecon.com<br>> <br>> FreeSWITCH-dev mailing list<br>> FreeSWITCH-dev@lists.freeswitch.org<br>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev<br>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev<br>> http://www.freeswitch.org<br></div> </div></body>
</html>