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

Joshua Colp jcolp at digium.com
Mon Jan 16 15:36:01 CET 2017


On Mon, Jan 16, 2017, at 10:26 AM, Daniel-Constantin Mierla wrote:
> 
> 
> On 16/01/2017 09:33, Daniel-Constantin Mierla wrote:
> >
> > On 16/01/2017 00:48, Joshua Colp wrote:
> >> On Sat, Jan 14, 2017, at 06:39 PM, Joshua Colp wrote:
> >>> On Sat, Jan 14, 2017, at 06:20 PM, Daniel-Constantin Mierla wrote:
> >>>> If you want a solution to avoid the issue via config: in the
> >>>> request_route, store the RPID in an avp and update the acc parameter to
> >>>> use the avp instead of the rpid variable.
> >>>>
> >>>> As for code, a solution could be resetting the 'hdr->parsed' pointers to
> >>>> NULL that are in private memory after memcpy(&tmsg, req,
> >>>> sizeof(sip_msg_t)); -- using same kind of loop like at the end of
> >>>> acc_onreply(), but wihout clean_hdr_field(). In this way it ensure that
> >>>> the acc is using only what it parses and it is freeing only those
> >>>> headers.
> >> We've been testing the configuration change and as expected it has
> >> resolved the problem. Thanks Daniel!
> >>
> > Welcome! I will try to fix it properly in the code as well.
> >
> I pushed a commit to do a deep cloning instead of just memcpy for the
> request structure. It should give a fresh structure without the headers
> that are not cloned in shared memory.
> 
> The solution with avp is still good, specially for older versions in
> order to avoid backporting, but if you get a chance to test and report
> the results, it will be appreciated. Besides seeing if there is still a
> crash, monitor the memory at the beginning and start of the tests just
> to see if there is a risk of a leak -- next commands can be used to see
> stats for private memory and shared memory:
> 
> kamcmd pkg.stats
> kamctl stats shmem

We've gone with the config change but I'll see what I can do with
testing the above in the future.

-- 
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