[asterisk-bugs] [JIRA] (ASTERISK-21406) [patch] chan_sip deadlock on monlock between unload_module and do_monitor

[Corey Farrell (JIRA)]

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

Corey Farrell commented on ASTERISK-21406:
------------------------------------------

Review reposted to https://reviewboard.asterisk.org/r/3284/ for switch to my new RB username.

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