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

[Filip Frank (JIRA)]

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

Filip Frank edited comment on ASTERISK-25321 at 8/20/15 7:25 AM:
-----------------------------------------------------------------

I analyze backtrace and lock log. I found problem in app_chanspy.c lines 572

ast_channel_lock(spyee_autochan->chan);
name = ast_strdupa(ast_channel_name(spyee_autochan->chan));
ast_channel_unlock(spyee_autochan->chan);

It locks channel, get name, unlock. But i see thread which holds lock is after this code. So i think chan in spyee_autochan structure was changed between lock and unlock. I write a patch spydeadlock.patch. With this patch it seems solve deadlock problems. I try about 280 thousands of calls without occur. Now we it testing on customer PBX. But i dont know if the patch is ok. Maybe better way is find which code change spyee_autochan->chan and add check for lock. 




was (Author: frenk77):
I analyze backtrace and lock log. I found problem in app_chanspy.c lines 572

ast_channel_lock(spyee_autochan->chan);
name = ast_strdupa(ast_channel_name(spyee_autochan->chan));
ast_channel_unlock(spyee_autochan->chan);

It locks channel, get name, unlock. But i see thread wchitch holds lock is after this code. So i think chan in spyee_autochan structure was changed between lock and unlock. I write a patch spydeadlock.patch. With this patch it seems solve deadlock problems. I try about 280 thousands of calls without occur. Now we it testing on customer PBX. But i dont know if the patch is ok. Maybe better way is find which code change spyee_autochan->chan and add check for lock. 



> 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
>    Affects Versions: 11.16.0, 11.18.0
>         Environment: custom CentOS 6 based distro
>            Reporter: Filip Frank
>            Assignee: Rusty Newton
>            Severity: Critical
>         Attachments: 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)