[Home]

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-0600Date Closed:2005-12-30 07:58:09.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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.