On Sat, Jan 14, 2017, at 01:55 PM, Daniel-Constantin Mierla wrote: <snip>
> >> The issues was with many processing handling the same transaction, which > >> has the sip_msg in shared memory, but then parsing of some headers > >> created pointers to private memory of the process doing the parsing. > >> Another process coming shortly after would see the pointer in sip_msg, > >> but it would be to another process private memory and accessing it does > >> a seg fault as expected. > > Thanks Daniel! Based on some logging I added I can confirm that the > > parsing did happen in another process, so I think you are right that > > this will fix the issue. I'm going to work on backporting the change and > > testing it out. > > > Do the testing, because as a first thought now looking at the acc code, > the fix might have just narrowed the race window. But not having any > other related report since the patch, nobody checked further. I would > need to see how the callback is executed in the tm for a proper > resolution, but no time right now. Testing is in progress and so far so good. I do think the code in acc_onreply that cleans up the parsed header is not correct, though. It's referencing the shared memory memory instead of the locally scoped one where any parsed headers (should) live. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev