|Summary:||ASTERISK-18277: Memory leak in chan_sip / realtime_peer() / mysql|
|Reporter:||Thomas Arimont (tomaso)||Labels:|
|Date Opened:||2011-08-15 17:19:23||Date Closed:||2011-08-23 13:23:11|
|Environment:||Attachments:||( 0) chan_sip_realtime_peer.patch|
( 1) extconfig_typical_sippeer.txt
( 2) memory_summary_chan_sip_res_config_mysql.log
( 3) valgrind_leak_check_after_10x_reloads.txt
( 4) valgrind_leak_check_before_reload.txt
|Description:||There is a memory leak in chan_sip / realtime_peer() which can at least be detected right after startup resp. after doing some further reloads (I haven't checked out the significance during normal call processing yet).|
See the attached valgrind leak-check results immediately after startup and after some further core reloads.
I have attached a patch which solves the problem.
The leak-check results seem to reveal a further memory leak in the ael module too.
|Comments:||By: Jonathan Rose (jrose) 2011-08-19 15:29:25.451-0500|
I'm trying to reproduce this bug on one of my test machines so that I can test this patch and I have some questions regarding your setup.
1. When I touch the configs and issue 'core reload' from CLI, I don't see any indication of realtime_peer being invoked. Is there something you are doing differently that would make core reload enter this function?
2. Can you attach extconfig.conf? I'd like to be able to see what specific settings you are using for realtime.
3. I'd like to see a typical sip peer in your realtime database. I'm noticing this patch mostly adds conditions for ast_variable list destruction, and when I was testing I was noticing some memory leaks when I had sip peers with setvar (more variables, more leaks too) in use, but this patch didn't seem to change that.
Also, if there is anything else you can think of to help me reproduce this, I'd appreciate it.
By: Jonathan Rose (jrose) 2011-08-19 15:31:02.193-0500
In the issue, I commented a request for some additional information. I've seen some memory leaks, but I'm still trying to reproduce memory leaks that the submitted patch fixes.
By: Thomas Arimont (tomaso) 2011-08-22 06:51:51.779-0500
o.k., after I 've tried to reproduce the effect of my patch to the detected memory leak once more I've come to the same result like you: no effect.
I will attach a file with the requested information. As you see 'setvar' is also in use in my mysql realtime peer configuration.
By: Jonathan Rose (jrose) 2011-08-22 13:39:12.087-0500
Richard Mudgett submitted a patch earlier that fixes a leak originating from a number of possible sources that use realtime variables (in config.c). I think he attached it to another issue of yours.
Also, as I was asking before, I'd really like to know what actual actions you are taking to produce the leak. Are you just registering and unregistering peers multiple times consecutively or are you doing something else? You mentioned core reload, but like I was saying before, core reload never touches the function which was reporting definite leaks that your patch applied to.
Right now I'm kind of sort of thinking it might be res_config_mysql that is the problem. If you could recompile with MALLOC_DEBUG (set via menuselect) recreate your memory leak for me and include the following:
memory show summary res_config_mysql.c
memory show summary chan_sip.c
that might help.
By: Thomas Arimont (tomaso) 2011-08-23 11:17:38.402-0500
the fix from ASTERISK-18265 (i.e. jira_asterisk_18265_v1.8_config.patch) solves also this problem.
So your assumption res_config_mysql is the problem seems to be right.
My suggested patch seemed reasonable but it definitely had no effect. As I have already said, my first verification was wrong.
Sorry, I did not mention. There was nothing else I had to do but "core reload" to reproduce the mem leak. And there are only two sip phones registered at the pbx (which are automatically re-registering , one with a subscription to state of the other).
I've attached the requested information.
By: Jonathan Rose (jrose) 2011-08-23 13:21:20.058-0500
Nah, actually if Richard's patch solved the problem then res_config_mysql was fine and it really was just config.c that was leaking. res_config_mysql was just where the variable allocation was requested. Thanks very much for the response though, it's very helpful to know that this was fixed for you, because I was basically completely incapable of reproducing the bug the way you have described it.