[asterisk-dev] IAX still broken

[Steve Kann]

Russell,

    The errors may be in the jb itself, but it may also be that there's 
some unusual delay in getting packets _into_ the jb which cause it to 
display those messages.  For example, if there's some single-threaded 
sections of code, or some kind of locking delays, etc.

    In the 19782 gdb output, you can see:
Thread 72 (process 19796):
#0  0xb7f82410 in __kernel_vsyscall ()
#1  0xb7e47cc6 in nanosleep () from /lib/libc.so.6
#2  0xb7e7544c in usleep () from /lib/libc.so.6
#3  0xb6dacbba in iax2_queue_frame (callno=40, f=0x83eebd0) at 
chan_iax2.c:1444
#4  0xb6dad60b in __get_from_jb (p=<value optimized out>) at 
chan_iax2.c:1804
#5  0xb6dcdd10 in iax2_process_thread (data=0x81f3d60) at chan_iax2.c:8259
#6  0x0812eb9d in ?? ()

Which seems to be from this code:
595 : 	matteo 	629 	static int iax2_queue_frame(int callno, struct 
ast_frame *f)
1596 : 	  	  	{
1597 : 	  	  	for (;;) {
1598 : 	  	  	if (iaxs[callno] && iaxs[callno]->owner) {
1599 : 	russell 	82728 
<http://svn.digium.com/view/asterisk/trunk/channels/chan_iax2.c?view=diff&r1=82727&r2=82728> 
	if (ast_channel_trylock(iaxs[callno]->owner)) {
1600 : 	matteo 	629 	/* Avoid deadlock by pausing and trying again */
1601 : 	markster 	1310 
<http://svn.digium.com/view/asterisk/trunk/channels/chan_iax2.c?view=diff&r1=1309&r2=1310> 
	ast_mutex_unlock(&iaxsl[callno]);
1602 : 	matteo 	629 	usleep(1);
1603 : 	markster 	1310 
<http://svn.digium.com/view/asterisk/trunk/channels/chan_iax2.c?view=diff&r1=1309&r2=1310> 
	ast_mutex_lock(&iaxsl[callno]);
1604 : 	matteo 	629 	} else {
1605 : 	markster 	2644 
<http://svn.digium.com/view/asterisk/trunk/channels/chan_iax2.c?view=diff&r1=2643&r2=2644> 
	ast_queue_frame(iaxs[callno]->owner, f);
1606 : 	russell 	82728 
<http://svn.digium.com/view/asterisk/trunk/channels/chan_iax2.c?view=diff&r1=82727&r2=82728> 
	ast_channel_unlock(iaxs[callno]->owner);
1607 : 	matteo 	629 	break;
1608 : 	  	  	}
1609 : 	  	  	}


The other output shows the same deadlock avoidance pattern in thread 73, 
Thread 56 (and, they seem to be different calls..).

-SteveK



Hendrik Visage wrote:
> On 10/9/07, Russell Bryant <russell at digium.com> wrote:
>
>   
>> Based on the console output that is in this file, it sounds like this a problem
>> that I have seen multiple times.  This appears to happen when the IAX2
>> jitterbuffer gets into some kind of bad state, indicated by the jitterbuffer
>> messages you see in the log.  There were reports of this against 1.2, as well as
>> all versions of 1.4.
>>     
>
>
> see attached typescript output.
>
>   
>> Perhaps if you could get a core dump from the system when it gets into this
>> state, it might provide some more insight.  If you do, get the gdb output of
>> "thread apply all bt" and "thread apply all bt full".  It would be even more
>> helpful if it were possible for you to provide access to the system for someone,
>> probably me, to take a look with gdb to try to figure out what happened.
>>
>> Thanks,
>>
>> --
>> Russell Bryant
>> Senior Software Engineer
>> Open Source Team Lead
>> Digium, Inc.
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>     
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

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