[asterisk-bugs] [Asterisk 0013173]: Asterisk blocked when 2 or more users leave a meetme when announce user is on

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13173 
====================================================================== 
Reported By:                pep
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13173
Category:                   Applications/app_meetme
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.21.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-07-27 05:46 CDT
Last Modified:              2008-08-25 10:20 CDT
====================================================================== 
Summary:                    Asterisk blocked when 2 or more users leave a meetme
when announce user is on
Description: 
If option I is used with meetme and 2 or more participants leave a
conference simultaneously, Asterisk stops working properly.  As the number
of simultaneous users leaving increases, the affect on Asterisk is
increased.

When the users hangup, zap channels stop accepting calls until the "user
has left the conference" message has played.  When several users leave
simultaneously the dialplan stops executing.
console commands such as meetme and core show channels will stop working. 
Sometimes the response is delayed by a few seconds and sometimes nothing is
returned at all.

When a larger number of users disconnect at the same time, Asterisk
becomes completely unusable without a restart
====================================================================== 

---------------------------------------------------------------------- 
 (0091691) putnopvut (administrator) - 2008-08-25 10:20
 http://bugs.digium.com/view.php?id=13173#c91691 
---------------------------------------------------------------------- 
The "core show locks" output is showing that thread 3083000720 is holding
the confs lock while thread 3082509200 is attempting to acquire it.

Typically with deadlocks, the problem is that both threads hold a lock
that the other is attempting to acquire, but in this case it appears that
the thread holding the lock is blocking in some other way and is thus not
reaching the point where the lock may be unlocked.

Looking at the code, the place that seems most likely to be causing the
problem is the call to ast_autoservice_stop in conf_play of app_meetme.c.
To help support this, it would be helpful to see a backtrace of the thread
which is currently holding the lock.

The easiest way to do this would be to upload a "thread apply all bt full"
output from gdb when the problem occurs. Unfortunately, this is a case
where the "core show locks" output was not enough to effectively determine
the cause of the deadlock, so further analysis is necessary. Thanks. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-25 10:20 putnopvut      Note Added: 0091691                          
======================================================================