14 Jan
2017
14 Jan
'17
1:43 p.m.
On Sat, Jan 14, 2017, at 01:55 PM, Daniel-Constantin Mierla wrote:
<snip>
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
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.