[asterisk-bugs] [Asterisk 0011972]: tls transport often causes asterisk to lock

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11972 
====================================================================== 
Reported By:                pj
Assigned To:                jamesgolovich
====================================================================== 
Project:                    Asterisk
Issue ID:                   11972
Category:                   Channels/chan_sip/General
Reproducibility:            random
Severity:                   block
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 103313 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-11-2008 11:04 CST
Last Modified:              02-18-2008 11:28 CST
====================================================================== 
Summary:                    tls transport often causes asterisk to lock
Description: 
when asterisk is locked, no call or registration is processed,
this happened several times today and yesterday (tried several trunk
revisions)
currently haven't found thing, what causes the locking situation, 
it seems, that locking problem start appearing, after more peers start
using tls transport
my tls only peers are: asterisk trunk, asterisk beta2 and eyebeam
sofphone
+several udp clients.



====================================================================== 

---------------------------------------------------------------------- 
 jamesgolovich - 02-18-08 11:28  
---------------------------------------------------------------------- 
On further checking it looks like the other 2 traces could be related
because it was forcing the dialog to be destroyed early (when the TCP/TLS
session went away).  

I added a bit of code in __sip_destroy to set p->stimer = NULL after
freeing it, so even if somehow code is checking if (p->stimer) it wont
segfault.

Also after sending around 3600 calls through 2 asterisks and occasionaly
removing network connectivity I was able to produce another crash.

I'm uploading another patch to try out. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-18-08 11:28  jamesgolovich  Note Added: 0082484                          
======================================================================