[asterisk-bugs] [Asterisk 0014619]: Asterisk crashes when Dial() to a sip channel terminates

Asterisk Bug Tracker noreply at bugs.digium.com
Sun Mar 8 20:13:07 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14619 
====================================================================== 
Reported By:                mapelletier
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14619
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!): 180677 
Request Review:              
====================================================================== 
Date Submitted:             2009-03-07 14:24 CST
Last Modified:              2009-03-08 20:13 CDT
====================================================================== 
Summary:                    Asterisk crashes when Dial() to a sip channel
terminates
Description: 
Inside Dial(), when either endpoint hangs up, the application crashes (gdb
backtrace included).  Problem does not occur on calls going through
Queue().
====================================================================== 

---------------------------------------------------------------------- 
 (0101344) mapelletier (reporter) - 2009-03-08 20:13
 http://bugs.digium.com/view.php?id=14619#c101344 
---------------------------------------------------------------------- 
Heap corruption when freeing memory and removing scheduler entry on
XMIT_FAILURE; it seems.

When it tries to validate the peers in DB, it does so /before/ sockip is
set in chan_sip.c.  Moving the initialization of peers after that of the
socket hides the problem (that is, removes the cause of XMIT_FAILURE). 
Once those failures occur, all hell break loose.

Regression introduced in r179220.  Problem hidden by changing a bit of
initialization order in chan_sip.c:reload_config() - but still extant.

Initializing peers after the socket is up is probably better in general
*anyways*; I'll provide a (trivial) patch if you want. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-08 20:13 mapelletier    Note Added: 0101344                          
======================================================================




More information about the asterisk-bugs mailing list