Cool thanks for the tip. One last question (I hope), core show channels does not list the sccp channel, it's already gone... If I read ast_queue_hangup correctly, it is trying to queue a frame on the channel. Would that also explain it?
I tried replacing ast_queue_hangup with ast_softhangup_nolock to test the locking theory before I posted the question, and it hung in basically the same manner. I have added a few ast_verbose calls around the suspected issue, and they confirm where it goes south. Dan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Russell Bryant Sent: Friday, June 01, 2007 12:38 PM To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] ast_queue_hangup when in a native bridge? Dan Austin wrote: > The bad news is that since I wrote and tested the > patch, something has changed. When the skinny > endpoint attempts to end the call with either > the 'EndCall' softkey or by going on hook, the > channel appears to hang in ast_queue_hangup() If it is hanging there, that means another thread has the channel locked. You could enable DEBUG_THREADS, and add some debug code to print out who has the channel locked, or attach with gdb to find out. See the ast_mutex_info structure in include/asterisk/lock.h. That is what is used for an ast_mutex_t when DEBUG_THREADS is enabled. -- Russell Bryant Software Engineer Digium, Inc. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
