[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-18 11:05 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
====================================================================== 

---------------------------------------------------------------------- 
 (0091515) putnopvut (administrator) - 2008-08-18 11:05
 http://bugs.digium.com/view.php?id=12969#c91515 
---------------------------------------------------------------------- 
callguy, thanks for the backtrace. I've not ever seen a crash occur in that
spot before.

There are two peculiarities with the backtrace provided. One is the actual
location of the crash. Unless there is some subtle memory corruption that
has never been caught before, an ast_log call with valid arguments should
not cause a crash. In order to figure this one out, it would probably be
quickest to use valgrind to determine what the error is.

The more peculiar thing is the spot in lock.h which was reached. This
place is only reached if a thread attempts to destroy a lock which is still
locked by another thread. This is an error condition that should not arise,
and it may be the issue in chanspy which has been causing other crashes
experienced by the original reporter. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-18 11:05 putnopvut      Note Added: 0091515                          
======================================================================