[Freeswitch-dev] [Freeswitch-users] origin/master's HEAD is segfaulting

arif hossain aftnix at live.com
Sat Jun 22 21:34:20 MSD 2013


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


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-dev mailing list