[asterisk-bugs] [Asterisk 0012969]: chanspy - crashes Asterisk - still

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12969 
====================================================================== 
Reported By:                kowalma
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12969
Category:                   Applications/app_chanspy
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.20.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-01 09:28 CDT
Last Modified:              2008-08-19 13:10 CDT
====================================================================== 
Summary:                    chanspy - crashes Asterisk - still
Description: 
Problem is same as in issue 11782. Chanspy crashes asterisk. I'll recompile
asterisk to fit settings decribed in docs/valgrind.txt
====================================================================== 

---------------------------------------------------------------------- 
 (0091556) putnopvut (administrator) - 2008-08-19 13:10
 http://bugs.digium.com/view.php?id=12969#c91556 
---------------------------------------------------------------------- 
I've had a look at the backtrace, and it appears that there is a race
condition in  app_chanspy that can happen if the spyee and spyer hang up
simultaneously.

There is a datastore used in app_chanspy which is attached to the spyee
channel when the spyer starts spying. The datastore is removed and freed if
either the spyee hangs up or if the spyer changes who he is spying on or
hangs up himself. The data which is stored in this datastore is a local
stacked structure in the spyer's thread. Part of this structure is a lock.
This lock is initialized when the spyer starts the chanspy application and
is destroyed when the spyer hangs up.

Now, this is an extremely tight race, but if my analysis is correct, it
seems as though the following set of circumstances could occur if both
spyee and spyer hang up at once.

1. ast_channel_free is called on the spyee's channel.
2. The chanspy datastore is removed from the spyee's channel in
ast_channel_free.
3. In the spyer's thread, the spyer attempts to remove and destroy the
datastore, but the datastore has already been removed from the spyee's
channel in step 2, so the spyer continues in the code.
4. The spyee's thread continues and calls the datastore's destroy
callback, which involves locking the lock I mentioned in the second
paragraph.
5. Now the spyer attempts to destroy the lock. The problem is that in step
4, the spyee has locked this lock, meaning that the spyer is attempting to
destroy a lock which is currently locked by another thread.

In analyzing this, I also noticed that perhaps this same situation could
arise if the spyer hangs up at the same moment that the spyee is
transferred by the far end. My analysis for this turned up a locking order
issue which could actually cause a deadlock.

So, what needs to be done is that some of app_chanspy's locking needs to
be re-examined in order to prevent both of the above scenarios from
occurring, no matter how rare the races may be. The crash associated with
the 5 step scenario I provided above can most likely be solved by placing a
lock/unlock sequence prior to the destruction of the lock. The potential
transfer deadlock, though, is another matter which will require a more
thoughtful solution. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-19 13:10 putnopvut      Note Added: 0091556                          
======================================================================