| Summary: | ASTERISK-12391: core show locks does not show all locks | ||
| Reporter: | Steve Murphy (murf) | Labels: | |
| Date Opened: | 2008-07-16 08:01:45 | Date Closed: | 2008-07-16 18:45:16 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| 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. ****** ADDITIONAL INFORMATION ****** 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. ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=131570 | ||