[asterisk-bugs] [JIRA] (ASTERISK-25321) [patch]DeadLock ChanSpy with call over Local channel

[Walter Doekes (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Walter Doekes updated ASTERISK-25321:
-------------------------------------

    Attachment: ASTERISK-25321_retry_chan_lock_until_stable.patch

So, after the very helpful comments of hexanol in IRC, I came up with this not so pretty fix in ASTERISK-25321_retry_chan_lock_until_stable.patch

{quote}
20:42 < hexanol> the ast_channel_lock will wait until the thread executing ast_do_masquerade unlocks the channel
20:43 < hexanol> the problem is, the pointer to the channel (spyee_autochan->chan) has already been evaluated before ast_channel_lock returns
20:43 < hexanol> so ast_channel_lock is called with a pointer X
20:43 < hexanol> and ast_channel_unlock is called with a pointer Y (X != Y)
20:57 < wdoekes> you may be right. going slow here. spyee_autochan->chan is X, we fetch that, at that point it gets swapped, and *then* we lock(X), which should've been Y. when unlocking it has in the mean time become Y so we unlock the wrong thing.
{quote}

Compiled tested only thusfar.

> [patch]DeadLock ChanSpy with call over Local channel
> ----------------------------------------------------
>
>                 Key: ASTERISK-25321
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25321
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_chanspy
>    Affects Versions: 11.16.0, 11.18.0
>         Environment: custom CentOS 6 based distro
>            Reporter: Filip Frank
>            Assignee: Filip Frank
>            Severity: Critical
>         Attachments: ASTERISK-25321_retry_chan_lock_until_stable.patch, asterisk.log_19082015_1258, backtrace-threads-ffr19082015_1258.txt, corelocks_ffr19082015_1258.txt, spydeadlock.patch
>
>
> We have a problem with ramdom deadlocks with using ChanSpy running on SIP channels, and dialing by AMI Originate to Local channel, which Dial another Local channel, and then Dial SIP peer. 
> Example: 1. SIP/iptel205 doing ChanSpy(SIP/iptel210)
>                2. AMI Originate Local/210 at dialer
>                3. Dial(Local/210 at internal)
>                4. Dial(SIP/iptel210)
>                5. Answer SIP/iptel210
>                6. Start dial caller from originate for ex 00420591122223 at outgoning
> Here is part of backtrace from coredump, I get it by gcore when asterisk was deadlocked.
> [Edit by Rusty - removed excessive debug from description. Please attach debug and annotated files to the issue with More > Attach Files]



--
This message was sent by Atlassian JIRA
(v6.2#6252)