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

[Corey Farrell (JIRA)]

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

Corey Farrell commented on ASTERISK-24555:
------------------------------------------

The frame cache interferes with the results of valgrind.  The leak backtrace you see likely isn't the code path that called {{ast_frdup}} without calling {{ast_frfree}}, it's more likely just the first caller of {{ast_frdup}} in the thread.  Disabling saving frames to the cache in {{__frame_free}} should fix this.  It will have some effect on performance but that shouldn't matter since you'd only do this for testing with valgrind.

[~mjordan] how would you feel about having frame.c support disabling cache through defined(LOW_MEMORY) || defined(DEBUG_VALGRIND)?  Or something similar, some way to add a #define separate from LOW_MEMORY for testing purposes.  DEBUG_VALGRIND would be for conditional code changes that could effect performance but fixes faulty results like incorrect leak backtraces caused by caches.

> 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
>         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.
> {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)