[asterisk-bugs] [JIRA] (ASTERISK-21389) res_timing_pthread fails to return from write, causing timer dependent operations to block indefinitely

[Shaun Ruffell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205075#comment-205075 ] 

Shaun Ruffell edited comment on ASTERISK-21389 at 4/8/13 5:47 PM:
------------------------------------------------------------------

I would like to review this later, but I have prepared a [patch against trunk|http://git.asterisk.org/gitweb/?p=team/sruffell/asterisk-working.git;a=patch;h=419f633aebc1c1f545d9f024973940464ae41c7c] which also [applies cleanly to 1.8|http://git.asterisk.org/gitweb/?p=team/sruffell/asterisk-working.git;a=shortlog;h=refs/heads/svn_1.8-res_timing_pthread].

This patch can be applied to your Asterisk working copy like:
{noformat}
curl "http://git.asterisk.org/gitweb/?p=team/sruffell/asterisk-working.git;a=patch;h=419f633aebc1c1f545d9f024973940464ae41c7c" | patch -p1
{noformat}


This patch basically puts the pipe in non-blocking mode and uses only the "pending_tick" member of the timer to control how many ticks are pending, and not also the number of bytes in the pipe. The pipe just has two states now...either there is a byte in it in order to make poll return as long as there are pending_ticks, or it's empty if there are no pending ticks.
                
      was (Author: sruffell):
    I would like to review this later, but I have prepared a [patch against trunk|http://git.asterisk.org/gitweb/?p=team/sruffell/asterisk-working.git;a=patch;h=419f633aebc1c1f545d9f024973940464ae41c7c] which also [applies cleanly to 1.8|http://git.asterisk.org/gitweb/?p=team/sruffell/asterisk-working.git;a=shortlog;h=refs/heads/svn_1.8-res_timing_pthread].

This patch basically puts the pipe in non-blocking mode and uses only the "pending_tick" member of the timer to control how many ticks are pending, and not also the number of bytes in the pipe. The pipe just has two states now...either there is a byte in it in order to make poll return as long as there are pending_ticks, or it's empty if there are no pending ticks.
                  
> res_timing_pthread fails to return from write, causing timer dependent operations to block indefinitely
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21389
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21389
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Resources/res_timing_pthread
>    Affects Versions: 1.8.20.0, 1.8.21.0
>            Reporter: Matt Jordan
>         Attachments: backtrace1-threads.txt, backtrace-threads.txt
>
>
> Tony from Schmooze Com reported that since upgrading to Asterisk 1.8.20.x, there have been numerous apparent lock ups in {{chan_sip}}, wherein all calls stop being processed. Other operations (such as querying from the CLI) continue to work correctly.
> Two backtraces taken from affected systems point to a call to {{res_timing_pthread}}'s write_byte not returning. This call is attempting to write a byte into a timer's pipe. In general, while the pipe is blocking, this operation should write the byte and immediately return. Failure to return typically indicates that the pipe is full.
> It isn't clear right now which timer is actually causing the problem, nor is it clear why a read operation isn't being performed on some timer. However, as noted in ASTERISK-14050, having a single timer run into this state will cause this exact problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira