[asterisk-bugs] [Asterisk 0015343]: lock in sip_tcp_helper_thread

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15343 
====================================================================== 
Reported By:                pj
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15343
Category:                   Channels/chan_sip/TCP-TLS
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 200254 
Request Review:              
====================================================================== 
Date Submitted:             2009-06-17 06:17 CDT
Last Modified:              2009-06-18 14:30 CDT
====================================================================== 
Summary:                    lock in sip_tcp_helper_thread
Description: 
Asterisk locked out during normal sip call processing. It seems, that bug
is in sip/tcp handling (one peer used sip over tcp when this lock
happened).

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

---------------------------------------------------------------------- 
 (0106678) mmichelson (administrator) - 2009-06-18 14:30
 https://issues.asterisk.org/view.php?id=15343#c106678 
---------------------------------------------------------------------- 
This is interesting. I can see from the "core show locks" output that the
tcptls_session->lock is held by thread -1275495568. This lock is not
supposed to be held for very long. In fact, the only thing that is done
with this lock held is to call fgets() to read input from the socket. For
some reason this call to fgets() is blocking indefinitely. This should not
happen, though, because there is a call to ast_wait_for_input earlier.

I'm not sure why this is happening. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-18 14:30 mmichelson     Note Added: 0106678                          
======================================================================