[asterisk-bugs] [JIRA] (ASTERISK-24555) Memory usage increases constantly (frame.c memory cache)
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Wed Dec 3 16:51:31 CST 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-24555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223862#comment-223862 ]
Matt Jordan commented on ASTERISK-24555:
----------------------------------------
So, I took a look at that area of the code again. I think there is another frame leak here that I missed when I wrote the patch for ASTERISK-19133. The code looks a bit different, but this is suspicious:
{code}
/* framehooks are called in __ast_read() before frame format
* translation is done, so we need to translate here */
if ((f->frametype == AST_FRAME_VOICE) && (f->subclass.format.id != AST_FORMAT_SLINEAR)
&& (readtrans = ast_channel_readtrans(active))) {
if ((f = ast_translate(readtrans, f, 1)) == NULL) {
f = &ast_null_frame;
ao2_ref(details, -1);
return f;
}
/* XXX we ignore the return value here, perhaps we should
* disable the gateway if a write fails. I am not sure how a
* write would fail, or even if a failure would be fatal so for
* now we'll just ignore the return value. */
gateway->s->tech->write(gateway->s, f);
ast_frfree(f);
} else {
gateway->s->tech->write(gateway->s, f);
}
f = &ast_null_frame;
ao2_ref(details, -1);
return f;
{code}
A few comments on this block:
* When we call {{ast_translate}}, we're calling it with the {{consume}} parameter set to true. That will automatically call {{ast_frfree}} on {{f}} when the function returns the translated frame. If we're calling this here, then we think that {{f}} has the potential to be {{malloc}}'d.
** Given how often a frame is dup'd or isolated, this is a safe bet.
* In that case, let's assume we don't call {{ast_translate}} here - which would be the case if we had a {{SLINEAR}} frame. In that case, we write the frame out to the fax technology, and then *immediately* blow over it with the {{ast_null_frame}}. That seems wrong. The gateway is never going to free the frame for us.
* We then return the {{ast_null_frame}}. The caller of this will be invoking the framehooks as such:
{code}
/* Perform the framehook write event here. After the frame enters the framehook list
* there is no telling what will happen, how awesome is that!!! */
if (!(fr = ast_framehook_list_write_event(ast_channel_framehooks(chan), fr))) {
res = 0;
goto done;
}
{code}
So {{fr}} is definitely nuked out by the invocation here. We're not going to free it anywhere else.
I've attached a patch that *may* fix this memory leak in your original setup. If you can test it out, that'd be hugely appreciated. Thanks!
> Memory usage increases constantly (frame.c memory cache)
> --------------------------------------------------------
>
> Key: ASTERISK-24555
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24555
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_iax2, Core/General
> Affects Versions: 11.14.0
> Environment: Ubuntu 11.10 x64
> Kernel 3.0.0-32
> cat /proc/cpuinfo:
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz
> stepping : 7
> cpu MHz : 2400.074
> cache size : 4096 KB
> physical id : 0
> siblings : 4
> core id : 0
> cpu cores : 4
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips : 4800.14
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz
> stepping : 7
> cpu MHz : 2400.074
> cache size : 4096 KB
> physical id : 0
> siblings : 4
> core id : 1
> cpu cores : 4
> apicid : 1
> initial apicid : 1
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips : 4800.18
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
> processor : 2
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz
> stepping : 7
> cpu MHz : 2400.074
> cache size : 4096 KB
> physical id : 0
> siblings : 4
> core id : 2
> cpu cores : 4
> apicid : 2
> initial apicid : 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips : 4800.18
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
> processor : 3
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz
> stepping : 7
> cpu MHz : 2400.074
> cache size : 4096 KB
> physical id : 0
> siblings : 4
> core id : 3
> cpu cores : 4
> apicid : 3
> initial apicid : 3
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips : 4800.18
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
> Reporter: James Lamanna
> Attachments: ASTERISK-24555-11.diff
>
>
> The memory allocation of Asterisk 11 seems to constantly increase.
> Specifically, the cache allocated in frame.c seems to increase without bound. I haven't let it go this far, but it seems it would likely max out system memory and be killed by the OOM killer.
> $ asterisk -rx "memory show summary" | sort -rn
> 3950471103 bytes allocated (3923172359 in caches) in 5289609 allocations
> 3922949255 bytes (3922882279 cache) in 5184358 allocations in file frame.c
> ..
> $ asterisk -rx "core show channels"
> 8 active channels
> 4 active calls
> 14745 calls processed
> $ asterisk -rx "core show uptime"
> System uptime: 2 days, 14 hours, 17 minutes, 32 seconds
> Last reload: 2 days, 14 hours, 17 minutes, 32 seconds
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list