[asterisk-bugs] [Asterisk 0013136]: [patch] sip peer qualified failed, asterisk lock.

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Oct 22 17:11:34 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=13136 
====================================================================== 
Reported By:                pabelanger
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   13136
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                        
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:             2008-07-23 02:32 CDT
Last Modified:              2009-10-22 17:11 CDT
====================================================================== 
Summary:                    [patch] sip peer qualified failed, asterisk lock.
Description: 
We just had asterisk lock on us tonight.  Best we can guess is because we
lost our SIP PEER (via qualify).

See output from 'show core locks'.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015894 SIP register via tls causes lock on sip...
====================================================================== 

---------------------------------------------------------------------- 
 (0112641) svnbot (reporter) - 2009-10-22 17:11
 https://issues.asterisk.org/view.php?id=13136#c112641 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 225490

_U  branches/1.6.1/
U   branches/1.6.1/apps/app_externalivr.c
U   branches/1.6.1/channels/chan_sip.c
U   branches/1.6.1/include/asterisk/tcptls.h
U   branches/1.6.1/main/tcptls.c

------------------------------------------------------------------------
r225490 | dvossel | 2009-10-22 17:11:33 -0500 (Thu, 22 Oct 2009) | 56
lines

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

........
  r225445 | dvossel | 2009-10-22 14:55:51 -0500 (Thu, 22 Oct 2009) | 50
lines
  
  SIP TCP/TLS: move client connection setup/write into tcp helper thread,
various related locking/memory fixes.
  
          What this patch fixes
  1.Moves sip TCP/TLS connection setup into the TCP helper thread:
    Connection setup takes awhile and before this it was being
    done while holding the monitor lock.
  2.Moves TCP/TLS writing to the TCP helper thread:  Through the
    use of a packet queue and an alert pipe, the TCP helper thread
    can now be woken up to write data as well as read data.
  3.Locking error: sip_xmit returned an XMIT_ERROR without giving
    up the tcptls_session lock.  This lock has been completely removed
    from sip_xmit and placed in the new sip_tcptls_write() function.
  4.Memory leak:  When creating a tcptls_client the tls_cfg was alloced
    but never freed unless the tcptls_session failed to start.  Now the
    session_args for a sip client are an ao2 object which frees the
    tls_cfg on destruction.
  5.Pointer to stack variable: During sip_prepare_socket the creation
    of a client's ast_tcptls_session_args was done on the stack and
    stored as a pointer in the newly created tcptls_session.  Depending
    on the events that followed, there was a slight possibility that
    pointer could have been accessed after the stack returned.  Given
    the new changes, it is always accessed after the stack returns
    which is why I found it.
  
  Notable code changes
  1.I broke tcptls.c's ast_tcptls_client_start() function into two
    functions.  One for creating and allocating the new tcptls_session,
    and a separate one for starting and handling the new connection.
    This allowed me to create the tcptls_session, launch the helper
    thread, and then establish the connection within the helper thread.
  2.Writes to a tcptls_session are now done within the helper thread.
    This is done by using an alert pipe to wake up the thread if new
    data needs to be sent.  The thread's sip_threadinfo object contains
    the alert pipe as well as the packet queue.
  3.Since the threadinfo object contains the alert pipe, it must now be
    accessed outside of the helper thread for every write (queuing of a
    packet).  For easy lookup, I moved the threadinfo objects from a
    linked list to an ao2_container.
  
  (closes issue https://issues.asterisk.org/view.php?id=13136)
  Reported by: pabelanger
  Tested by: dvossel, whys
  
  (closes issue https://issues.asterisk.org/view.php?id=15894)
  Reported by: dvossel
  Tested by: dvossel
  
  Review: https://reviewboard.asterisk.org/r/380/
........

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-22 17:11 svnbot         Checkin                                      
2009-10-22 17:11 svnbot         Note Added: 0112641                          
======================================================================




More information about the asterisk-bugs mailing list