[asterisk-bugs] [Asterisk 0010886]: Crash in local_queue_frame trying to trylock a corrupted p->owner lock

noreply at bugs.digium.com noreply at bugs.digium.com
Fri Oct 12 15:46:20 CDT 2007


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10886 
====================================================================== 
Reported By:                ChaseVenters
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10886
Category:                   Addons/General
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-04-2007 13:02 CDT
Last Modified:              10-12-2007 15:46 CDT
====================================================================== 
Summary:                    Crash in local_queue_frame trying to trylock a
corrupted p->owner lock
Description: 
It appears that local_queue_frame() is trying to lock a mutex that has been
destroyed (or is otherwise corrupt). The reentrancy value is 7903722 and
the pthread struct contains a value __m_owner = 0xbad, which is probably a
magic cookie for a mutex that has been destroyed.

In frame 1, isoutbound is 1, making other p->owner, making the corrupted
lock &p->owner->lock.
====================================================================== 

---------------------------------------------------------------------- 
 ChaseVenters - 10-12-07 15:46  
---------------------------------------------------------------------- 
I was. I turned off all the debugging options the other day after studying
lock.h -- it looks like the debugging code is vulnerable to a number of
race conditions. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-12-07 15:46  ChaseVenters   Note Added: 0071907                          
======================================================================




More information about the asterisk-bugs mailing list