No subject

is that in the function get_sip_pvt_byid_locked, both the sip_pvt_ptr and
sip_pvt_ptr->owner get locked. For some reason, they are not getting
unlocked, though. Because the sip_pvt_ptr->owner remains locked, the
attempt to show channels falls into an infinite loop because it continually
is attempting to lock that channel and failing.

The tricky part of this is figuring out why those locks were not released
in a timely manner. I suspect that since you say that calls were still
processed correctly that there are some missing unlock statements that need
to be added. I could be wrong however, and it could be that chan_sip is
hanging somewhere prior to the correct releasing points of those locks.
What complicates this even further is that the only way
get_sip_pvt_ptr_byid_locked is called is when a transfer is involved,
meaning that keeping track of channel information through masquerades can
be cumbersome.

By the way, I think you can avoid all those ??'s in the backtraces if
instead of killing asterisk, you attach to the deadlocked asterisk process
with gdb and get your backtraces there. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-10-08 11:05  putnopvut      Note Added: 0076669                          
======================================================================