Summary:ASTERISK-12391: core show locks does not show all locks
Reporter:Steve Murphy (murf)Labels:
Date Opened:2008-07-16 08:01:45Date Closed:2008-07-16 18:45:16
Versions:Frequency of
Description:In my research for 12772, when using the log_show_lock
routine to help me see who had a channel lock when a
request was made for it, I came up with nothing. It
was not recorded in the lock_info lists.
I have since done some research and determined
that it does not seem to be getting removed by
subsequent activity.

****** STEPS TO REPRODUCE ******

log_show_lock in main/utils.c is a routine that will
test a mutex with the try_lock routine and if it is
busy, then it will search for the mutex in the
lock_info lists, and when it finds a match, will
publish the info via ast_log.

I used it before and after a channel lock
in the sip invite code, and in the __ast_answer
code, and it never could find the channel lock
in question. I then expanded my copy of
log_show_lock to show all the locks that *are*
recorded, and indeed, of the few locks in the
list, nothing close to the channel lock I knew
existed was in the lists.


I found this bug, and intend to also fix it, so
I thought it fitting I open a report on it.
This might (maybe) explain why "core show locks"
on a deadlocked machine does not always
reveal a deadlock, and it might be worth our
time, from a QA perspective, to get this fixed.
Comments:By: Russell Bryant (russell) 2008-07-16 08:03:37

Can you provide a simple test case that can help someone else observe the problem?

By: Digium Subversion (svnbot) 2008-07-16 18:45:13

Repository: asterisk
Revision: 131570

U   trunk/include/asterisk/lock.h

r131570 | murf | 2008-07-16 18:45:11 -0500 (Wed, 16 Jul 2008) | 20 lines

(closes issue ASTERISK-12391)
Reported by: murf

Most of this bug was already fixed by Tilghman before
I opened it; Many thanks to Tilghman for his fix
in svn version 125794. That fix cleared up some of the
fields in the lock_info.

This commit changes the address that is stored for the
lock in the lock_info struct, so that it is the same
as that passed into the locking macros. This makes
searching for a lock_info (as in log_show_lock())
by its lock addr possible. The lock_addr field is
infinitely more useful if it is the same as what
is 'publicly' available outside the lock_info code.

Many thanks to kpfleming, putnopvut, and Russell for their
invaluable insights earlier today.