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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13136 
====================================================================== 
Reported By:                pabelanger
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13136
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-07-23 02:32 CDT
Last Modified:              2008-11-18 19:22 CST
====================================================================== 
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'.
====================================================================== 

---------------------------------------------------------------------- 
 (0095040) putnopvut (administrator) - 2008-11-18 19:22
 http://bugs.digium.com/view.php?id=13136#c95040 
---------------------------------------------------------------------- 
Back in the early days of this bug, when I was looking at it, my idea was
to do exactly what you did in your latest patch, Corydon76. That is, set
the socket to non-blocking prior to calling connect and then poll/select
until the socket is ready for writing.

What I found when initially writing this is that there are a bunch of
places that you have to check for errors. Every call to fcntl, the call to
connect, the call to getsockopt, the call to select/poll, etc. It may be
that some of these functions are erroring out for some reason. Adding error
checking/logging may point to some portion that is failing to execute
properly. 

Also, I'm not sure about the legality/correctness of this, but my original
intention was also to clear the O_NONBLOCK flag on the socket after I had
determined that the connection was successful. I don't think this would
directly affect the problem encountered, but hey, just throwing something
else out there.

Another possibility is that the non-blocking connect patch is properly
solving the original problem but blitzrage's testing may have uncovered
something else wrong. The fact that there are locks held, but there is no
contention between threads makes me think that the monitor thread in
chan_sip is blocking somewhere, somehow. I would assume that the call to
write in ast_tcptls_server_write is now blocking for some reason.

Something else to consider is that pabelanger said that the issue is not
present in trunk or 1.6.1. It may be worthwhile to see what fixes were made
there with regards to TCP support in chan_sip and see if we can identify
which revision fixed this issue. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-18 19:22 putnopvut      Note Added: 0095040                          
======================================================================