Summary: | ASTERISK-06039: [patch] app_queue has a deadlock when weight is used | ||
Reporter: | zoa (zoa) | Labels: | |
Date Opened: | 2006-01-11 05:44:56.000-0600 | Date Closed: | 2011-06-07 14:00:41 |
Priority: | Blocker | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_queue |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) queue_deadlock.patch | |
Description: | We were contacted by a someone with a deadlocking machine, after some testing it turned out that the weight option was the cause of the problem. (disabling the weight, fixed it) We identified the offending code and patched it, (+ tested it) i will upload the diff later today. This patch was paid for by [.J.B from S.] | ||
Comments: | By: zoa (zoa) 2006-01-11 05:45:32.000-0600 all asterisk versions we tested seemed to have the problem (1.0.x 1.2.x). By: zoa (zoa) 2006-01-11 06:25:42.000-0600 patch uploaded. By: Peng Yong (ppyy) 2006-01-11 09:12:36.000-0600 no patch file. pls upload it By: zoa (zoa) 2006-01-11 09:16:15.000-0600 patch now really really really uploaded :) By: zoa (zoa) 2006-01-11 11:48:58.000-0600 patch is yesterdays version of asterisk. (will doublecheck if it was head or stable) By: zoa (zoa) 2006-01-11 12:05:45.000-0600 cvs head By: Tilghman Lesher (tilghman) 2006-01-21 23:00:04.000-0600 This patch isn't likely to get committed. The problem is, we really do need both of those locks: we need qlock because compare_weights() needs it when traversing the list, and we need chan->lock because we're accessing channel structures, and we don't want the channel to go away while we're referencing those values. Another solution needs to be found. By: Tilghman Lesher (tilghman) 2006-03-06 17:21:38.000-0600 Bug closed due to no response. If you have a new patch, please reopen this bug or have a bug marshal open it for you. |