[asterisk-bugs] [JIRA] (ASTERISK-24555) Memory leak with T.38 fax and SLINEAR format

[Etienne Allovon (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241340#comment-241340 ] 

Etienne Allovon edited comment on ASTERISK-24555 at 1/4/18 3:35 AM:
--------------------------------------------------------------------

Hello,

We were tracking this issue as we saw the problem on several asterisk at customer site.
Following [~coreyfarrell] comment I checked on several production asterisk :
- the problem is no longer seen on two asterisk that were upgraded in 13.10.0
- whereas the problem is still seen on an asterisk that is still in 13.7.2

So, IMHO, I would answer, to [~coreyfarrell] above question: _No, it is no longer an issue in current asterisk 13 version_


was (Author: etienne_pf):
Hello,

We were tracking this issue as we saw the problem on several asterisk at customer site.
Following [~coreyfarrell] comment I checked on several production asterisk :
- the problem is no longer seen on an asterisk that was upgraded in 13.10.0
- whereas the problem is still seen on an asterisk that is still in 13.7.2

So, IMHO, I would answer, to [~coreyfarrell] above question: _No, it is no longer an issue in current asterisk 13 version_

> Memory leak with T.38 fax and SLINEAR format
> --------------------------------------------
>
>                 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, Resources/res_fax
>    Affects Versions: 11.14.0, 13.18.4
>         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
>            Assignee: 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.
> {noformat}
> $ 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 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)