[asterisk-bugs] [Asterisk 0012584]: Lock errors on the CLI

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12584 
====================================================================== 
Reported By:                DougUDI
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12584
Category:                   Channels/chan_local
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-05-2008 10:05 CDT
Last Modified:              05-12-2008 12:05 CDT
====================================================================== 
Summary:                    Lock errors on the CLI
Description: 
We have seen lock errors on a few different servers running 1.4.19. These
seem to be mostly related to the queues. If anyone can please shed som
light on these errors. In some cases the system seems to stop call delivery
on the queues.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 05-12-08 12:05  
---------------------------------------------------------------------- 
A few notes here:

@DougUDI: In your original bug description, the timestamps are out of
order on the messages. Did you re-arrange them or did they actually appear
in that order? This information could make a big difference in trying to
track this issue down. Also, uploading chan_local.so is useless since .so
files are compiled and don't mean anything to the average developer and
also since we can use svn to get whatever revision of chan_local.c you are
presently using.

@jyap: I'd recommend that you disable the DEBUG_CHANNEL_LOCKS compiler
option. It's pretty much a subset of DETECT_DEADLOCKS, and in a case such
as this one, it actually hinders the ability to determine where a deadlock
is occurring. The reason for this is that when DEBUG_CHANNEL_LOCKS is on,
there is a single function that all channel locks stem from, and so that
same function is shown in the core show locks output for all channels that
are locked. In contrast, when DEBUG_CHANNEL_LOCKS is disabled,
ast_channel_lock is a macro, meaning that the core show locks output will
show exactly where the call to ast_channel_lock was made.

@all: I looked at the code for about an hour and I while I can't say for
sure the circumstances behind this, it seems like this is probably stemming
from a race condition between threads and their lock operations. I'll have
more information as I figure out more. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-12-08 12:05  putnopvut      Note Added: 0086727                          
======================================================================