[asterisk-bugs] [JIRA] (ASTERISK-24555) Memory leak with T.38 fax and SLINEAR format
dtryba (JIRA)
noreply at issues.asterisk.org
Thu Jan 15 10:23:35 CST 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-24555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=224500#comment-224500 ]
dtryba commented on ASTERISK-24555:
-----------------------------------
I think I'm affected by this bug, patching with ASTERISK-24392 was not enough to stop leaking. But fun fact is that source and destination agree on alaw (the only joint capability), but while FAXOPT(gateway) is attached the read/write format is slin. This machine runs out of memory every 2 weeks since FAXOPT(gateway) was enabled.
{quote}
res_fax.c: channel 'SIP/inas1sbc01-00003fe6' setting FAXOPT(gateway) to 'yes,10'
res_fax.c: Selected FAX technology module (Spandsp FAX Driver) does not support reserving sessions.
res_fax.c: Attached T.38 gateway to channel SIP/inas1sbc01-00003fe6.
features.c: Removing dialed interfaces datastore on SIP/sip.pocos.nl-00003fe8 since we're bridging
channel.c: Set channel SIP/inas1sbc01-00003fe6 to read format slin
channel.c: Set channel SIP/inas1sbc01-00003fe6 to write format slin
channel.c: Set channel SIP/sip.pocos.nl-00003fe8 to read format slin
channel.c: Set channel SIP/sip.pocos.nl-00003fe8 to write format slin
res_rtp_asterisk.c: Setting the marker bit due to a source update
res_rtp_asterisk.c: Setting the marker bit due to a source update
res_rtp_asterisk.c: 0x7f70efc06130 -- Probation learning mode pass with source address 109.235.32.40:35260
res_rtp_asterisk.c: Ooh, format changed from unknown to alaw
res_rtp_asterisk.c: Created smoother: format: alaw ms: 20 len: 160
res_rtp_asterisk.c: Starting RTCP transmission on RTP instance '0x7f70f08f1418'
chan_sip.c: Stopping retransmission on 'SDsefm801-282901960c8ebe0ac043c1da4b1dc7df-a8b8583' of Response 98699154: Match Found
res_rtp_asterisk.c: 0x7f70f0c8eb90 -- Probation learning mode pass with source address 139.156.204.193:23766
res_rtp_asterisk.c: Ooh, format changed from unknown to alaw
res_rtp_asterisk.c: Created smoother: format: alaw ms: 20 len: 160
res_fax.c: no fax activity between SIP/inas1sbc01-00003fe6 and SIP/sip.pocos.nl-00003fe8 after 10000 ms, disabling gateway
channel.c: Set channel SIP/inas1sbc01-00003fe6 to read format alaw
channel.c: Set channel SIP/sip.pocos.nl-00003fe8 to read format alaw
channel.c: Set channel SIP/sip.pocos.nl-00003fe8 to write format alaw
channel.c: Set channel SIP/inas1sbc01-00003fe6 to write format alaw
{quote}
> 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
> Assignee: Matt Jordan
> 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)
More information about the asterisk-bugs
mailing list