On Tue, May 12, 2009 at 3:31 PM, Michael Broughton < Michael_Broughton at advanis.ca> wrote: > > > Benny Prijono wrote: > >> >> The rtp_src_addr is registered to pj_ioqueue_recvfrom(), so it will be >> filled up by the ioqueue when it calls on_rx_rtp() callback. So >> theoretically in the callback the value is always valid. >> >> Unless if this is that ugly race condition thing, where attach() is being >> called while a packet is being received... I recall you reported a similar >> case Michael (http://trac.pjsip.org/repos/ticket/460). >> >> > > Hi Benny, > > That is actually what I was thinking. I have been trying to figure out if > it is possible that transport_attach() in transport_udp.c is being called at > the same time as an rtp/rtcp packet is arriving. > > Basically, I am getting an assertion failure in on_rx_rtcp() in > transport_udp.c, when it calls: > > pj_sockaddr_print(&udp->rtcp_src_addr, ...); > > This comes right after this call: > > pj_memcpy(&udp->rem_rtcp_addr, &udp->rtcp_src_addr, ...); > > When I debug the coredump, udp->rtcp_src_addr is all zero's (hence the > assertion failure in pj_sockaddr_print), but udp->rem_rtcp_addr is a > valid/correct address. I don't see how this could happen unless another > thread is overwriting that memory location. > > Yep. I added a ticket for this (http://trac.pjsip.org/repos/ticket/844), along with a patch in the ticket attachment for the potential fix. Still need to think about this a bit more to make sure we won't get those pesky deadlock though. thanks Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090512/b8058afd/attachment.html>
