[asterisk-bugs] [JIRA] (ASTERISK-30394) [patch] DUNDi process_clearcache() can result in deadlock

[Joshua C. Colp (JIRA)]

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

Joshua C. Colp commented on ASTERISK-30394:
-------------------------------------------

Your patch is showing up, I think you uploaded it at the same time I replied.

> [patch] DUNDi process_clearcache() can result in deadlock
> ---------------------------------------------------------
>
>                 Key: ASTERISK-30394
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30394
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: PBX/pbx_dundi
>    Affects Versions: 20.1.0
>            Reporter: Peter Racz
>            Assignee: Unassigned
>            Severity: Major
>              Labels: patch
>         Attachments: dundi-clearcache.patch
>
>
> The method process_clearcache() in pbx_dundi.c does not handle thread cancelling correctly. The code is trying to limit the cancellation to within the 60s sleep call. However, it is not correct.
> From the man page for pthread_cancel():
> {quote}
> A  thread's  cancelability  state,  determined  by   pthread_setcancel‐
> state(3), can be enabled (the default for new threads) or disabled.  If
> a thread has disabled cancellation, then a cancellation request remains
> queued  until the thread enables cancellation.  If a thread has enabled
> cancellation, then its cancelability type determines when  cancellation
> occurs.
> A  thread's  cancellation type, determined by pthread_setcanceltype(3),
> may be either asynchronous or deferred (the default for  new  threads).
> Asynchronous cancelability means that the thread can be canceled at any
> time (usually immediately, but the system  does  not  guarantee  this).
> Deferred  cancelability  means  that cancellation will be delayed until
> the thread next calls a function that is a cancellation point.  A  list
> of  functions  that  are  or  may be cancellation points is provided in
> pthreads(7).
> {quote}
> Additionally, if a thread holds a mutex when it is cancelled, the mutex will remain locked, and any future attempts to lock the mutex will block forever.
> In the code, the cancellation is deferred to a cancellation point. Most blocking IO operations are cancellation points. ast_db_gettree() and ast_db_del() take the dblock mutex and then performs IO operations on the sqlite3 database. So the cancellation can happen when the dblock is held, and then subsequent calls to ast_db operations blocks forever.
> The patch sets pthread_setcancelstate() to disabled except while performing the sleep. The patch is against the latest version in git.
> Remark: The deadlock probably does not happen in practice with the latest Asterisk version but the code is buggy. We use a somewhat modified reload() method and then we see this issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)