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 _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
