[sr-dev] Remote-Party-ID Parsed Header Crash

Joshua Colp jcolp at digium.com
Sat Jan 14 19:43:56 CET 2017


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



More information about the sr-dev mailing list