16 Jan
2017
16 Jan
'17
9:36 a.m.
On Mon, Jan 16, 2017, at 10:26 AM, Daniel-Constantin Mierla wrote:
On 16/01/2017 09:33, Daniel-Constantin Mierla wrote:
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
On 16/01/2017 00:48, Joshua Colp wrote:
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 On Sat, Jan 14, 2017, at 06:39 PM, Joshua Colp
wrote:
Welcome! I will try to fix it properly in the code as well.
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!