[asterisk-bugs] [JIRA] (ASTERISK-29101) chan_sip: Deadlock with res_rtp_asterisk
Kevin Harwell (JIRA)
noreply at issues.asterisk.org
Thu Oct 15 09:50:36 CDT 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-29101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Harwell updated ASTERISK-29101:
-------------------------------------
Description:
Hi all.
I have an asterisk server installed with version 16.1.1 on centos 7 Os.
I have noticed that sometimes my all SIP peers going unreachable including the looping SIP trunk(127.0.0.1) which I have. I was checking for the locks in asterisk using asterisk -rx “core show locks” and below is my result.
{noformat}
===
=== Thread ID: 0x7f1ea0930700 LWP:30389 (do_monitor started at [29979] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 29340 handle_request_do &netlock 0x7f1f01b2f680 (1)
asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa33d6) [0x7f1f018ff3d6]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
asterisk(ast_io_wait+0x7a) [0x4f517a]
/usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
asterisk() [0x5a0412]
/usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
/usr/lib64/libc.so.6(clone+0x6d) [0x7f1f25caf02d]
=== ---> Lock #1 (chan_sip.c): MUTEX 9370 sip_pvt_lock_full pvt 0x7f1e000661a0 (1)
asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
asterisk(__ao2_lock+0x1c5) [0x45d7f5]
/usr/lib64/asterisk/modules/chan_sip.so(+0x14bd5) [0x7f1f01870bd5]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa3405) [0x7f1f018ff405]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
asterisk(ast_io_wait+0x7a) [0x4f517a]
/usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
asterisk() [0x5a0412]
/usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
/usr/lib64/libc.so.6(clone+0x6d) [0x7f1f25caf02d]
=== ---> Lock #2 (rtp_engine.c): MUTEX 692 ast_rtp_instance_set_prop instance 0x7f1e000347c0 (1)
asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
asterisk(__ao2_lock+0x1c5) [0x45d7f5]
asterisk(ast_rtp_instance_set_prop+0x29) [0x53ed79]
/usr/lib64/asterisk/modules/chan_sip.so(+0x27ee4) [0x7f1f01883ee4]
/usr/lib64/asterisk/modules/chan_sip.so(+0x95f88) [0x7f1f018f1f88]
/usr/lib64/asterisk/modules/chan_sip.so(+0x9771c) [0x7f1f018f371c]
/usr/lib64/asterisk/modules/chan_sip.so(+0x9a820) [0x7f1f018f6820]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa0bcd) [0x7f1f018fcbcd]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa351e) [0x7f1f018ff51e]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
asterisk(ast_io_wait+0x7a) [0x4f517a]
/usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
asterisk() [0x5a0412]
/usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
{noformat}
was:
Hi all.
I have an asterisk server installed with version 16.1.1 on centos 7 Os.
I have noticed that sometimes my all SIP peers going unreachable including the looping SIP trunk(127.0.0.1) which I have. I was checking for the locks in asterisk using asterisk -rx “core show locks” and below is my result.
===
=== Thread ID: 0x7f1ea0930700 LWP:30389 (do_monitor started at [29979] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 29340 handle_request_do &netlock 0x7f1f01b2f680 (1)
asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa33d6) [0x7f1f018ff3d6]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
asterisk(ast_io_wait+0x7a) [0x4f517a]
/usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
asterisk() [0x5a0412]
/usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
/usr/lib64/libc.so.6(clone+0x6d) [0x7f1f25caf02d]
=== ---> Lock #1 (chan_sip.c): MUTEX 9370 sip_pvt_lock_full pvt 0x7f1e000661a0 (1)
asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
asterisk(__ao2_lock+0x1c5) [0x45d7f5]
/usr/lib64/asterisk/modules/chan_sip.so(+0x14bd5) [0x7f1f01870bd5]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa3405) [0x7f1f018ff405]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
asterisk(ast_io_wait+0x7a) [0x4f517a]
/usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
asterisk() [0x5a0412]
/usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
/usr/lib64/libc.so.6(clone+0x6d) [0x7f1f25caf02d]
=== ---> Lock #2 (rtp_engine.c): MUTEX 692 ast_rtp_instance_set_prop instance 0x7f1e000347c0 (1)
asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
asterisk(__ao2_lock+0x1c5) [0x45d7f5]
asterisk(ast_rtp_instance_set_prop+0x29) [0x53ed79]
/usr/lib64/asterisk/modules/chan_sip.so(+0x27ee4) [0x7f1f01883ee4]
/usr/lib64/asterisk/modules/chan_sip.so(+0x95f88) [0x7f1f018f1f88]
/usr/lib64/asterisk/modules/chan_sip.so(+0x9771c) [0x7f1f018f371c]
/usr/lib64/asterisk/modules/chan_sip.so(+0x9a820) [0x7f1f018f6820]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa0bcd) [0x7f1f018fcbcd]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa351e) [0x7f1f018ff51e]
/usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
asterisk(ast_io_wait+0x7a) [0x4f517a]
/usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
asterisk() [0x5a0412]
/usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
> chan_sip: Deadlock with res_rtp_asterisk
> ----------------------------------------
>
> Key: ASTERISK-29101
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29101
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General, Resources/res_rtp_asterisk
> Affects Versions: 16.1.1
> Environment: CentOS Linux release 7.6.1810 (Core)
> Reporter: Vijo Jose
> Assignee: Vijo Jose
>
> Hi all.
> I have an asterisk server installed with version 16.1.1 on centos 7 Os.
> I have noticed that sometimes my all SIP peers going unreachable including the looping SIP trunk(127.0.0.1) which I have. I was checking for the locks in asterisk using asterisk -rx “core show locks” and below is my result.
> {noformat}
> ===
> === Thread ID: 0x7f1ea0930700 LWP:30389 (do_monitor started at [29979] chan_sip.c restart_monitor())
> === ---> Lock #0 (chan_sip.c): MUTEX 29340 handle_request_do &netlock 0x7f1f01b2f680 (1)
> asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
> /usr/lib64/asterisk/modules/chan_sip.so(+0xa33d6) [0x7f1f018ff3d6]
> /usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
> asterisk(ast_io_wait+0x7a) [0x4f517a]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
> asterisk() [0x5a0412]
> /usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
> /usr/lib64/libc.so.6(clone+0x6d) [0x7f1f25caf02d]
> === ---> Lock #1 (chan_sip.c): MUTEX 9370 sip_pvt_lock_full pvt 0x7f1e000661a0 (1)
> asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
> asterisk(__ao2_lock+0x1c5) [0x45d7f5]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x14bd5) [0x7f1f01870bd5]
> /usr/lib64/asterisk/modules/chan_sip.so(+0xa3405) [0x7f1f018ff405]
> /usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
> asterisk(ast_io_wait+0x7a) [0x4f517a]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
> asterisk() [0x5a0412]
> /usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
> /usr/lib64/libc.so.6(clone+0x6d) [0x7f1f25caf02d]
> === ---> Lock #2 (rtp_engine.c): MUTEX 692 ast_rtp_instance_set_prop instance 0x7f1e000347c0 (1)
> asterisk(__ast_pthread_mutex_lock+0x85) [0x501885]
> asterisk(__ao2_lock+0x1c5) [0x45d7f5]
> asterisk(ast_rtp_instance_set_prop+0x29) [0x53ed79]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x27ee4) [0x7f1f01883ee4]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x95f88) [0x7f1f018f1f88]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x9771c) [0x7f1f018f371c]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x9a820) [0x7f1f018f6820]
> /usr/lib64/asterisk/modules/chan_sip.so(+0xa0bcd) [0x7f1f018fcbcd]
> /usr/lib64/asterisk/modules/chan_sip.so(+0xa351e) [0x7f1f018ff51e]
> /usr/lib64/asterisk/modules/chan_sip.so(+0xa4fcf) [0x7f1f01900fcf]
> asterisk(ast_io_wait+0x7a) [0x4f517a]
> /usr/lib64/asterisk/modules/chan_sip.so(+0x8086c) [0x7f1f018dc86c]
> asterisk() [0x5a0412]
> /usr/lib64/libpthread.so.0(+0x7dd5) [0x7f1f2690cdd5]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list