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

[Dirk Wendland (JIRA)]

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

Dirk Wendland edited comment on ASTERISK-25321 at 2/24/16 4:36 AM:
-------------------------------------------------------------------

Hello together

same issue here like the post from Jesper with asterisk 11.21.2 (callflow).

{NOFORMAT}
(gdb) thread 209
[Switching to thread 209 (Thread 0x7f1aec3ef700 (LWP 9019))]#0  0x0000003a66e0e334 in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) f 2
#2  0x0000003a66e094d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) info reg
rax            0xfffffffffffffe00	-512
rbx            0x7f1b2402bbf8	139754545003512
rcx            0xffffffffffffffff	-1
rdx            0x5b23e0	5972960
rsi            0x80	128
rdi            0x7f1b2402bba0	139754545003424
rbp            0x5bc18e	0x5bc18e
rsp            0x7f1aec3ee1c8	0x7f1aec3ee1c8
r8             0x7f1b2402bba0	139754545003424
r9             0x233b	9019
r10            0x3f6	1014
r11            0x246	582
r12            0x7f1aec3ee5f0	139753609422320
r13            0x0	0
r14            0x7f1b28002020	139754611941408
r15            0x1	1
rip            0x3a66e094d7	0x3a66e094d7 <pthread_mutex_lock+103>
eflags         0x246	[ PF ZF IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb) p *(pthread_mutex_t*) 0x7f1b2402bba0
$13 = {__data = {__lock = 2, __count = 1, __owner = 9058, __nusers = 1, __kind = 1, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, 
  __size = "\002\000\000\000\001\000\000\000b#\000\000\001\000\000\000\001", '\000' <repeats 22 times>, __align = 4294967298}
{NOFORMAT}
The thread is allready dead ( 9058 ) that causes the deadlock so it looks like a lock without unlock.



was (Author: kesselklopfer79):
Hello together

same issue here like the post from Jesper with asterisk 11.21.2.

{NOFORMAT}
(gdb) thread 209
[Switching to thread 209 (Thread 0x7f1aec3ef700 (LWP 9019))]#0  0x0000003a66e0e334 in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) f 2
#2  0x0000003a66e094d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) info reg
rax            0xfffffffffffffe00	-512
rbx            0x7f1b2402bbf8	139754545003512
rcx            0xffffffffffffffff	-1
rdx            0x5b23e0	5972960
rsi            0x80	128
rdi            0x7f1b2402bba0	139754545003424
rbp            0x5bc18e	0x5bc18e
rsp            0x7f1aec3ee1c8	0x7f1aec3ee1c8
r8             0x7f1b2402bba0	139754545003424
r9             0x233b	9019
r10            0x3f6	1014
r11            0x246	582
r12            0x7f1aec3ee5f0	139753609422320
r13            0x0	0
r14            0x7f1b28002020	139754611941408
r15            0x1	1
rip            0x3a66e094d7	0x3a66e094d7 <pthread_mutex_lock+103>
eflags         0x246	[ PF ZF IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb) p *(pthread_mutex_t*) 0x7f1b2402bba0
$13 = {__data = {__lock = 2, __count = 1, __owner = 9058, __nusers = 1, __kind = 1, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, 
  __size = "\002\000\000\000\001\000\000\000b#\000\000\001\000\000\000\001", '\000' <repeats 22 times>, __align = 4294967298}
{NOFORMAT}
The thread is allready dead ( 9058 ) that causes the deadlock so it looks like a lock without unlock.


> [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.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)