Summary: | ASTERISK-05933: [patch] Race issue in channel.c involving uniqueint (non-unique UniqueID generated) | ||
Reporter: | Werner Johansson (wj) | Labels: | |
Date Opened: | 2005-12-30 05:03:21.000-0600 | Date Closed: | 2005-12-30 07:58:09.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) channel.c.diff | |
Description: | We have faced a problem with non-unique UniqueID:s attached to channels when originating lots of calls at once in async mode using the manager interface. This creates problems for us trying to map channel events like link and call progress to a specific ActionID being supplied to the Originate action. Tracking down the code that calculates the uniqueid (in channel.c) and looking at the code generated by the compiler it is obvious that this piece of code isn't thread safe (non-atomic increment of the call id). If this happens before the time variable changes there will be more than one channel with the same ID, which obviously is bad. If the UniqueID is never used this probably won't affect operation, but for us that is the only way to see which channel belongs to which call, as the ActionID isn't passed down to the actual channel structure (i.e we only get ActionID on OriginateSuccess, but never on Newstate for instance). This has been spotted running Asterisk 1.2.1, but no changes to this code can be seen in the newer revisions on channel.c in the trunk or on the 1.2 branch. We have developed a quick fix which seems to work, but there might be some other way to implement this. Patch for channel.c included below, comments appreciated! Patch is based on the 1.2.1 release of the code, but no relevant changes has been made in the 1.2 branch or the trunk. ****** ADDITIONAL INFORMATION ****** It's not completely true that this bug is "always" reproducible, but "sometimes" and "random" are too vague - it's always reproducible if the code gets interrupted between the initial load of uniqueint into a CPU register and the following write back (more than enough time to be interrupted). Disclaimer on it's way, not on file yet. | ||
Comments: | By: Werner Johansson (wj) 2005-12-30 07:25:59.000-0600 Disclaimer faxed. By: Tilghman Lesher (tilghman) 2005-12-30 07:57:52.000-0600 Committed to 1.2, merged to trunk. |