[asterisk-bugs] [JIRA] (ASTERISK-16169) app_queue's compare_weight can be called in contexts that don't lock the global queues lock

[Sean Bright (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-16169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean Bright updated ASTERISK-16169:
-----------------------------------

    Description: 
I haven't experienced any crashes from this issue but I thought I would report it anyway.

I noticed in the code that ring_one() is called from both try_calling() and wait_for_answer(). The former goes through a lot of trouble to lock the queues lock if we're using weights. The queues lock is then unlocked right before wait_for_answer() is called. But wait_for_answer() can also call ring_one(), which calls ring_entry(), which calls compare_weight(). And compare_weight() walks the queues list (in 1.4) or iterates the queue ao2 (in trunk).

As a side note: ever thought about creating an ast_assert_locked() macro that could be used in places that compare_weight that assume locks, to output a warning if that assumption is ever violated?

  was:
I haven't experienced any crashes from this issue but I thought I would report it anyway.

I noticed in the code that ring_one() is called from both try_calling() and wait_for_answer(). The former goes through a lot of trouble to lock the queues lock if we're using weights. The queues lock is then unlocked right before weight_for_answer() is called. But wait_for_answer() can also call ring_one(), which calls ring_entry(), which calls compare_weight(). And compare_weight() walks the queues list (in 1.4) or iterates the queue ao2 (in trunk).

As a side note: ever thought about creating an ast_assert_locked() macro that could be used in places that compare_weight that assume locks, to output a warning if that assumption is ever violated?


> app_queue's compare_weight can be called in contexts that don't lock the global queues lock
> -------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-16169
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16169
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Applications/app_queue
>            Reporter: Tim Ringenbach at Asteria Solutions Group
>
> I haven't experienced any crashes from this issue but I thought I would report it anyway.
> I noticed in the code that ring_one() is called from both try_calling() and wait_for_answer(). The former goes through a lot of trouble to lock the queues lock if we're using weights. The queues lock is then unlocked right before wait_for_answer() is called. But wait_for_answer() can also call ring_one(), which calls ring_entry(), which calls compare_weight(). And compare_weight() walks the queues list (in 1.4) or iterates the queue ao2 (in trunk).
> As a side note: ever thought about creating an ast_assert_locked() macro that could be used in places that compare_weight that assume locks, to output a warning if that assumption is ever violated?



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