[asterisk-bugs] [JIRA] (ASTERISK-17969) Asterisk 1.8.2.3 crashes when dialling from IAX2 to IAX2

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-17969:
----------------------------------------

I have a feeling that this was actually a duplicate of ASTERISK-19597.

In ASTERISK-19597, it was found that an AST_CONTROL_HOLD frame could be passed without a suggested MoH class. This would leave junk in the data pointer, with a datalen of 0. The relevant portion from the patch on that issue shows where this was fixed:

{noformat}
+	/*
+	 * Clear fr->af.data if there is no data in the buffer.  Things
+	 * like AST_CONTROL_HOLD without a suggested music class must
+	 * have a NULL pointer.
+	 */
+	if (!fr->af.datalen) {
+		memset(&fr->af.data, 0, sizeof(fr->af.data));
+	}
{noformat}

I'm going to go ahead and close this out as a duplicate of ASTERISK-19597. If you or someone else is still running into this problem with IAX2 to IAX2 calls, please let a bug marshal know in #asterisk-bugs and we'll reopen the issue.
                
> Asterisk 1.8.2.3 crashes when dialling from IAX2 to IAX2
> --------------------------------------------------------
>
>                 Key: ASTERISK-17969
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17969
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 1.8.2
>         Environment: OS: gentoo 2.6.36; 8GB RAM; intel 2.6GHz dual quad core hyper threaded
>            Reporter: ppower
>         Attachments: backtrace.txt, valgrind.txt
>
>
> When I do something like this:
> IAX -> dial(some_number)
> some_number,1,Dial(SIP/XXX,10) ; do not answer
> some_number,n,Answer()
> some_number,n,Wait(1)
> some_number,n,Dial(IAX/some_number_on_the_same_server,60)
> asterisk crashes.  I tried removing the Answer and Wait, but no crash.
> A long story brought me here. I am trying to upgrade our systems from 1.2.31 to 1.8.2.3.
> running 30 to 40 phones on a server worked and continues to work just fine.
> Triple that number or so and periodic problems started; SIP registrations failed , IAX calls failed, unresponsive servers at the CLI, Max retries exceeded to host XXX on IAX2/XXX messages showed up and killing asterisk to restart is was the only way to get back control.
> Since this problem appears to be IAX related, a little IAX torture test was created. 
> When IAX calls are directed back to the server the number of active IAX channels goes up.
> Eventually the MAX retries thing starts happening, CPU gets very busy, VMStats reports very large number of context switches.  If asterisk retains some control, the number of IAX channels sometimes goes down. 
> After looking at other posted issues (ASTERISK-16711,ASTERISK-16258,ASTERISK-13156 and possibly others). I have the DAHDI timing module loaded only and the number of IAX threads set to 1. Now i am left with the short dial plan shown above and a regularly crashing server. When IAX debugging is set on the asterisk does not crash. When asterisk retains control i notice the CPU and context switching significantly increase when one dial ends and another begins.  the number of IAX channels required to do this less than 40. 
> DONT_OPTIMIZE and DEBUG_THREADS are set ON
> I have a core dump and will provide a back trace when i figure out how to use this jira thing :)
> here is a snippet:
> Program terminated with signal 11, Segmentation fault.
> #0  0x00007f7eb34518d9 in free () from /lib/libc.so.6
> #0  0x00007f7eb34518d9 in free () from /lib/libc.so.6
> No symbol table info available.
> #1  0x00007f7e97ac8fc6 in free_signaling_queue_entry (s=0x7f7ea4e0c650) at chan_iax2.c:1823
> No locals.
> #2  0x00007f7e97ac9027 in send_signaling (pvt=0x7f7ea5826a68) at chan_iax2.c:1835
>         s = 0x7f7ea4e0c650
> #3  0x00007f7e97af2ed5 in socket_process (thread=0x7f7e867923f0) at chan_iax2.c:10252
> This is a very reproducible problem.
> Let me know what i can to help out with this. Please let me know what i may need to do differently (fist time posting an issue).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira