[asterisk-bugs] [JIRA] (ASTERISK-21406) [patch] chan_sip deadlock on monlock between unload_module and do_monitor
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Fri Mar 28 13:54:48 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-21406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Jordan updated ASTERISK-21406:
-----------------------------------
Target Release Version/s: 11.9.0
> [patch] chan_sip deadlock on monlock between unload_module and do_monitor
> -------------------------------------------------------------------------
>
> Key: ASTERISK-21406
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-21406
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General
> Affects Versions: 1.8.24.0, 11.4.0
> Environment: Ubuntu/quantal, eglibc-2.15-0ubuntu20
> Reporter: Corey Farrell
> Assignee: Corey Farrell
> Target Release: 1.8.27.0, 11.9.0
>
> Attachments: chan_sip-unload-deadlock-backtrace.txt, chan_sip-unload-deadlock-debug.patch, chan_sip-unload-testfix.patch
>
>
> unload_module cancels/joins the monitor thread while holding monlock. If do_monitor attempts to lock monlock while unload_module already has it, they deadlock. do_monitor waits for monlock while unload_module waits for do_monitor to exit.
> I've experienced this issue a couple of times in production when attempting to shutting down. I found the cause while running valgrind tests. I believe valgrind slowed things down so much it caused the deadlock to occur somewhat reliably. I could not replicate the issue with lock debugging enabled. I added ast_log messages to unload_module, found that they stopped while monlock was held. The valgrind testing was done with 'make samples', no changes to /etc/asterisk. I tried attaching gdb once the lock occured but it could not find symbols (probably because of valgrind).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list