Merged revisions 138886 via svnmerge from
authorMark Michelson <mmichelson@digium.com>
Tue, 19 Aug 2008 18:52:04 +0000 (18:52 +0000)
committerMark Michelson <mmichelson@digium.com>
Tue, 19 Aug 2008 18:52:04 +0000 (18:52 +0000)
commitb949d5347e1de04799b160d4aac73f7b37445a82
treea10fe95901ab747571365682db5efb56b958ce06
parent3f3b1d4dad945826698effe85c06a63410e8500c
Merged revisions 138886 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r138886 | mmichelson | 2008-08-19 13:50:53 -0500 (Tue, 19 Aug 2008) | 23 lines

Add a lock and unlock prior to the destruction of the chanspy_ds
lock to ensure that no other threads still have it locked. While
this should not happen under normal circumstances, it appears that
if the spyer and spyee hang up at nearly the same time, the following
may occur.

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
   from the spyee channel, but the datastore has already been removed in step 2,
   so the spyer continues in the code.
4. The spyee's thread continues and calls the datastore's destroy callback,
   chanspy_ds_destroy. This involves locking the chanspy_ds.
5. Now the spyer attempts to destroy the chanspy_ds 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.

The backtrace provided in issue #12969 supports the idea that this is possible
(and has even occurred). This commit does not close the issue, but should help
in preventing one type of crash associated with the use of app_chanspy.

........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
apps/app_chanspy.c