[asterisk-bugs] [Asterisk 0016678]: [patch] segfault on chanspy due to race in main/channel.c

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Feb 12 17:33:39 CST 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16678 
====================================================================== 
Reported By:                tim_ringenbach
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   16678
Category:                   Applications/app_chanspy
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     closed
Target Version:             1.4.31
Asterisk Version:           1.4.29 
JIRA:                       SWP-783 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-01-22 17:52 CST
Last Modified:              2010-02-12 17:33 CST
====================================================================== 
Summary:                    [patch] segfault on chanspy due to race in
main/channel.c
Description: 
When channel.c destroys the datastore on the channel, it doesn't hold the
channel lock while calling the destroy callback. It really ought to,
because otherwise it's accessing the datastore list without locking. I've
gotten a segfault trying to lock the mutex in the ds destroy function in
app_chanspy because of this race.

Holding the channel lock during the destroy should be safe because it is
also held during the fixup callback, and app_chanspy has already been
patched to avoid the possible deadlock from that locking order issue.
====================================================================== 

---------------------------------------------------------------------- 
 (0118056) svnbot (reporter) - 2010-02-12 17:33
 https://issues.asterisk.org/view.php?id=16678#c118056 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 246547

_U  branches/1.6.2/
U   branches/1.6.2/main/channel.c

------------------------------------------------------------------------
r246547 | dvossel | 2010-02-12 17:33:38 -0600 (Fri, 12 Feb 2010) | 28
lines

Merged revisions 246546 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r246546 | dvossel | 2010-02-12 17:32:33 -0600 (Fri, 12 Feb 2010) | 21
lines
  
  Merged revisions 246545 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r246545 | dvossel | 2010-02-12 17:30:17 -0600 (Fri, 12 Feb 2010) | 16
lines
    
    lock channel during datastore removal
    
    On channel destruction the channel's datastores are removed and
    destroyed.  Since there are public API calls to find and remove
    datastores on a channel, a lock should be held whenever datastores are
    removed and destroyed.  This resolves a crash caused by a race
    condition in app_chanspy.c.
    
    (closes issue https://issues.asterisk.org/view.php?id=16678)
    Reported by: tim_ringenbach
    Patches:
          datastore_destroy_race.diff uploaded by tim ringenbach (license
540)
    Tested by: dvossel
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=246547 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-12 17:33 svnbot         Checkin                                      
2010-02-12 17:33 svnbot         Note Added: 0118056                          
======================================================================




More information about the asterisk-bugs mailing list