[asterisk-bugs] [JIRA] (ASTERISK-21409) Race condition with IAX2 transfer, 2 releases happen on same call legs. locks up with many threads blocked by iax2_destroy_helper

[Alec Davis (JIRA)]

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

Alec Davis edited comment on ASTERISK-21409 at 6/5/13 3:11 AM:
---------------------------------------------------------------

attached iax2_transfer_diff2.txt

refactored IAX_COMMAND_TXREADY decision logic.
.1 get a lock on both legs if bridgecallno exists.

.2 these tests are now needed as we the pvt is unlocked for Deadlock avoidance
.2a check if transferring == MBEGIN then MREADY
.2b check if transferring == BEGIN then READY
.2c else if transferrring!= above tests then exit

.3a remove redundant checks of thisside->MREADY||READY, we can use the bridgedcallno-transferring.
.3b when checking bridgedcallno->transferring positively identify MREADY or READY

testing.
many test call using ORIGINATE(), never wen't wrong
CLI output:

With locking, never would go wrong :)
    -- IAX2/auckland-20910 is proceeding passing it to IAX2/auckland-17388
    -- IAX2/auckland-20910 answered IAX2/auckland-17388
    -- Channel 'IAX2/auckland-20910' ready to transfer
    -- Channel 'IAX2/auckland-17388' ready to transfer
    -- Releasing IAX2/auckland-17388 and IAX2/auckland-20910

=== Examples without locking: ===

Without locking bridgecallno I could get the order wrong!
    -- IAX2/auckland-19071 is proceeding passing it to IAX2/auckland-17663
    -- IAX2/auckland-19071 answered IAX2/auckland-17663
    -- Channel 'IAX2/auckland-19071' ready to transfer
    -- Releasing IAX2/auckland-19071 and IAX2/auckland-17663
    -- Channel 'IAX2/auckland-17663' ready to transfer

Another wrong sequence without locking, server is under load - disk back up.
These 2 interleave each thread.
    -- Channel 'IAX2/auckbdt-19065' ready to transfer
    -- Channel 'IAX2/auckbdt-20047' ready to transfer
    -- Releasing IAX2/auckbdt-19065 and IAX2/auckbdt-20047
    -- Releasing IAX2/auckbdt-20047 and IAX2/auckbdt-19065
    -- Channel 'IAX2/auckbdt-19065' finished transfer (this is just before we exit the case statement)
    -- Channel 'IAX2/auckbdt-20047' finished transfer


   

                
      was (Author: alecdavis):
    attached iax2_transfer_diff2.txt

refactored IAX_COMMAND_TXREADY decision logic.
.1 get a lock on both legs if bridgecallno exists.

.2 these tests are now needed as we the pvt is unlocked for Deadlock avoidance
.2a check if transferring == MBEGIN then MREADY
.2b check if transferring == BEGIN then READY
.2c else if transferrring!= above tests then exit

.3a remove redundant checks of thisside->MREADY||READY, we can use the bridgedcallno-transferring.
.3b when checking bridgedcallno->transferring positively identify MREADY or READY

testing.
many test call using ORIGINATE(), never wen't wrong
CLI output:

Without locking bridgecallno I could get the order wrong - once!
    -- IAX2/auckland-19071 is proceeding passing it to IAX2/auckland-17663
    -- IAX2/auckland-19071 answered IAX2/auckland-17663
    -- Channel 'IAX2/auckland-19071' ready to transfer
    -- Releasing IAX2/auckland-19071 and IAX2/auckland-17663
    -- Channel 'IAX2/auckland-17663' ready to transfer

With locking, never would go wrong :)
    -- IAX2/auckland-20910 is proceeding passing it to IAX2/auckland-17388
    -- IAX2/auckland-20910 answered IAX2/auckland-17388
    -- Channel 'IAX2/auckland-20910' ready to transfer
    -- Channel 'IAX2/auckland-17388' ready to transfer
    -- Releasing IAX2/auckland-17388 and IAX2/auckland-20910



   

                  
> Race condition with IAX2 transfer, 2 releases happen on same call legs. locks up with many threads blocked by iax2_destroy_helper
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21409
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21409
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 1.8.15.0, 11.3.0
>         Environment: Debian Squeeze
>            Reporter: Alec Davis
>         Attachments: coreshowlocks-31may.txt, full.may08.C-0000034cd.txt, gdb-31may.txt, iax2_transfer.diff2.txt, iax2_transfer.diff.txt, iax-coreshowlocks-may08-auckland.txt, iax-lock-asterisk-11.txt, iax-lock-asterisk-1-8-15.txt, var_log_messages.txt
>
>
> Intermittently all IAX calls stop over the trunk.
> I think this is reproduced when a call is transferred back to the originating site, we have "transfer=on"
> Also happened with asterisk SVN-branch-11-r382514.
> Attached are the 1.8.15.0 lockup, and the 11-branch lockup.
>  

--
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