[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:              03-04-2008 17:44 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.



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

---------------------------------------------------------------------- 
 russell - 03-04-08 17:44  
---------------------------------------------------------------------- 
> Theres a few other changes in here that were necessary to stop deadlocks.

> One was to only lock netlock for udp channels and the other was to
change 
> the local in the monitor thread from a lock to a trylock.

I didn't merge in those netlock changes yet, because I was a bit worried
about it.  Basically, my concern is that the netlock currently ensures that
only one SIP request is being processed at a time.  Changing that could
cause a lot of bugs to come out due to that being an assumption in the code
everywhere.  I'd be interested in seeing the deadlock that this avoided,
though.  The same goes for the trylock change.  I'd like to see exactly
what the deadlock is that it avoids before we put that in.

> Also I added a little sleeping when unloading the module to give it
enough
> time for any threads to die. I was getting a strange crash when
unloading 
> if the threads didn't die quick enough.

Hm, I don't understand what the problem was here, either.  The
pthread_join() above your usleep() waits until the thread exist before
continuing.

> There were some other crashes happening when the SSL fd would go away
but
> server_write was still being called, so thats why I added the check for

> ser->fd and set errno and return -1 there.

Ok, I'm fine with this santiy check.  I'd like to see an ERROR message in
there, too, though, since really, this should never happen, and we should
try to track down how it does happen.  I'll add this change into the
branch.

> I'm compiling your branch right now and gonna hammer at it to see if I 
> can reproduce any crash or deadlocks

Sounds great.  If you can reproduce anything, let me know here.  Thanks
for the help! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-04-08 17:44  russell        Note Added: 0083382                          
======================================================================