[asterisk-dev] Coredump upon receipt of RTP with 183sessionprogress on

Power, Paul C. ppower at oneeighty.com
Thu Sep 20 16:27:36 CDT 2007


Valgrind output before the crash:
 
==17954== 
==17954== Invalid read of size 4
==17954==    at 0x8267E2D: autocorr (helpfun.c:36)
==17954==    by 0x54B46FA: coder_ld8a (in
/usr/lib/asterisk/modules/codec_g729a.so)
==17954==    by 0x54B462E: g729_coder (in
/usr/lib/asterisk/modules/codec_g729a.so)
==17954==    by 0x543A4DD: (within
/usr/lib/asterisk/modules/codec_g729a.so)
==17954==    by 0x80F585C: ast_translate (translate.c:335)
==17954==    by 0x8086DF8: ast_write (channel.c:2877)
==17954==    by 0x80AADBD: playtones_generator (indications.c:191)
==17954==    by 0x8083F87: ast_read_generator_actions (channel.c:2160)
==17954==    by 0x80859F9: __ast_read (channel.c:2513)
==17954==    by 0x8085BAD: ast_read (channel.c:2549)
==17954==    by 0x8130E4D: wait_for_answer (app_dial.c:689)
==17954==    by 0x8133EFA: dial_exec_full (app_dial.c:1283)
==17954==  Address 0xC is not stack'd, malloc'd or (recently) free'd
==17954== 
==17954== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==17954==  Access not within mapped region at address 0xC
==17954==    at 0x8267E2D: autocorr (helpfun.c:36)
==17954==    by 0x54B46FA: coder_ld8a (in
/usr/lib/asterisk/modules/codec_g729a.so)
==17954==    by 0x54B462E: g729_coder (in
/usr/lib/asterisk/modules/codec_g729a.so)
==17954==    by 0x543A4DD: (within
/usr/lib/asterisk/modules/codec_g729a.so)
==17954==    by 0x80F585C: ast_translate (translate.c:335)
==17954==    by 0x8086DF8: ast_write (channel.c:2877)
==17954==    by 0x80AADBD: playtones_generator (indications.c:191)
==17954==    by 0x8083F87: ast_read_generator_actions (channel.c:2160)
==17954==    by 0x80859F9: __ast_read (channel.c:2513)
==17954==    by 0x8085BAD: ast_read (channel.c:2549)
==17954==    by 0x8130E4D: wait_for_answer (app_dial.c:689)
==17954==    by 0x8133EFA: dial_exec_full (app_dial.c:1283)
==17954== 
==17954== ERROR SUMMARY: 232375 errors from 415 contexts (suppressed: 7
from 1)
==17954== malloc/free: in use at exit: 1,484,508 bytes in 7,032 blocks.
==17954== malloc/free: 22,955 allocs, 15,923 frees, 5,291,035 bytes
allocated.
==17954== For counts of detected errors, rerun with: -v
==17954== searching for pointers to 7,032 not-freed blocks.
==17954== checked 12,836,600 bytes.
==17954== 
==17954== LEAK SUMMARY:
==17954==    definitely lost: 298 bytes in 2 blocks.
==17954==      possibly lost: 3,456 bytes in 24 blocks.
==17954==    still reachable: 1,480,754 bytes in 7,006 blocks.
==17954==         suppressed: 0 bytes in 0 blocks.
==17954== Rerun with --leak-check=full to see details of leaked memory.

I have added logging to the code to try to deterime what might be
drastically wrong, but i have not seen anything (presuming i would
notice).


________________________________

	From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Power, Paul
C.
	Sent: Thursday, September 20, 2007 8:35 AM
	To: Asterisk Developers Mailing List
	Subject: Re: [asterisk-dev] Coredump upon receipt of RTP with
183sessionprogress on
	
	
	Some thing i forgot to mention the first time:
	when progressinband=never or no, the call out to the PSTN works
like a charm.


________________________________

		From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Power, Paul
C.
		Sent: Wednesday, September 19, 2007 4:37 PM
		To: asterisk-dev at lists.digium.com
		Subject: [asterisk-dev] Coredump upon receipt of RTP
with 183 sessionprogress on
		
		
		Hello every body. 
		 
		I originally ran into the problem on * 1.4.10, but am
able to replicate quite nicly on 1.4.11.
		 
		I have asterisk installed on gentoo. Using a Polycom 601
phone, codec g729. trying to dial out to the PSTN via an openSER proxy
with an Audiocodes gateway.
		 
		progressinband is set to yes.
		 
		When i dial out to the PSTN asterisk dies upon the
receipt of the first RTP packet from the phone. i have traced the
problem to the ast_rtp_read call in rtp.c.  i have looked into things to
the point that i know when an RTP packet comes from the phone and
rtp->f.samples (line 1300) value is set to 160 (in my case), the
function call does not return to the place it came from (asterisk
crashes).  i have experimented a bit by manulally setting rtp->f.samples
to various values.
		 
		when set to 0 asterisk does not die, it contiues to run.
		when set to 1 asterisk dies after receiving a few dozen
RTP packets.
		when set to 31 asterisk dies after receiving 3-4 RTP
packets.
		so, the higher the samples value the quicker the death.
		 
		(gdb) bt
		#0  0x08267e69 in autocorr (r=0x869e6c4, x=0xc,
N=-1228178720, order=222647369) at helpfun.c:38
		#1  0xb6f656fb in coder_ld8a () from
/usr/lib/asterisk/modules/codec_g729a.so
		#2  0xb6f6562f in g729_coder () from
/usr/lib/asterisk/modules/codec_g729a.so
		#3  0xb6eeb4de in ?? () from
/usr/lib/asterisk/modules/codec_g729a.so
		#4  0x0869e6c4 in ?? ()
		#5  0x086a0688 in ?? ()
		#6  0x086a4548 in ?? ()
		#7  0xb6cb7dd8 in ?? ()
		#8  0xb78e2ff4 in ?? () from /lib/libc.so.6
		#9  0x00000000 in ?? ()
		 
		I am pretty much at a loss as to where to look or what
to do to resolve this issue.
		Any suggestions would be welcomed.  If there is any
additional information that people would like to see, i will try to
provide.
		 
		-PCPIII
		 
		 
		 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070920/99dbd737/attachment.htm 


More information about the asterisk-dev mailing list