[asterisk-bugs] [Asterisk 0012155]: race condition between sip hangup and "core show channel xxx" results in crash

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12155 
====================================================================== 
Reported By:                tsearle
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12155
Category:                   Resources/res_features
Reproducibility:            sometimes
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-06-2008 02:56 CST
Last Modified:              03-10-2008 11:32 CDT
====================================================================== 
Summary:                    race condition between sip hangup and "core show
channel xxx" results in crash
Description: 
sometimes when the command "core show channel (channel name)" it results in
a crash when trying to print the contents of the channels cdr object. 
Analysis of the core dumps have show this to always occur at the same time
the channel is in the process of hanging up.

Following the code backwards I found that the root cause was in
res_features.c
After shutting down the bridge, it frees the channel cdr object without
first locking the channel to make sure it's safe.

Attached is a patch that introduces locking.
====================================================================== 

---------------------------------------------------------------------- 
 tsearle - 03-10-08 11:32  
---------------------------------------------------------------------- 
I don't know if it is possible for another thread to free the channel while
res_features is using it (normally this is the the thread that should be
freeing it, not another thread and the original version of this method had
no locking at all)

The crash I was dealing with was not a result of the channel being freed
it was an issue of channel->cdr being freed without locking.

This is now prevented as follows
1. lock chan
2. free chan->cdr
3. set chan->cdr to null (so it is not possible to reference freed memory
after releasing the lock, which was the root cause of the crash)
4. unlock chan, repeat the same for the peer

also, I do not hold both channel locks at the same time to avoid deadlock
scenarios.

I have done load testing to the crash regarding the c->cdr pointer to
verify that no longer occurs. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-10-08 11:32  tsearle        Note Added: 0083676                          
======================================================================