New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users
Status: Untriaged
Owner: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment
Windows bug in webrtc/system_wrappers/interface/tick_util.h
Reported by, Apr 3 2013 Back to list
What steps will reproduce the problem?

In tick_util.h has following code;

 (C1) DWORD now = timeGetTime();                                      
 (C2) DWORD old = InterlockedExchange(lastTimeGetTimePtr, now);
 (C3) if ((now < old) && (old > 0xf0000000 && now < 0x0fffffff)) { numWrapTimeGetTime++; }
 (C4) result = now + (numWrapTimeGetTime<<32);

 Thread Sequence (now/old)

 Thread 1     Thread 2      Thread 3       Last       Wrap
 (C1) 99/                                   90         0
 Context Switch
              (C1) 2/
              (C2) 2/90                      2         
              (C3) Yes                                 1
              (C4) result:102
 (C2) 99/2                                  99
 (C3) no
 (C4) result:199 (BUG!)
                            (C1) 5/
                            (C2) 5/99        5
                            (C3) Yes                   2
                            (C4) result:205 (BUG!)

What is the expected result?

  Correct absolute timestamp returned

What do you see instead?

  Incorrect timestamp

What version of the product are you using? On what operating system?
Project Member Comment 1 by, Apr 8 2013
@Patrick, could you please help to take a look at this?
Project Member Comment 2 by, Apr 9 2013
Status: Assigned
Comment 3 by, Apr 11 2013
Labels: -Pri-2 Pri-3
I agree with the assessment that this code is not thread safe during wraparound.

The simple way of fixing this would be to acquire a lock but doing so would likely cause a performance hit so we don't want to do that.

Trying to fix this in a lock free way is risky as it is very likely to introduce subtle issues.

The likelihood of this happening is very small. On average a wraparound happens every ~49.7/2 days. In addition, at the time of wraparound a thread that was about to increment the wraparound counter must have been preempted by another thread beating it to the punch for there to be a data race.

If a very incorrect timestamp is generated e.g. to mark the capture time of a frame it would be caught by sanity checks. I.e. the worst thing that would happen is that a frame would be dropped.

The risk vs reward of trying to fix this is heavily skewed towards risk. Assigning to Niklas to figure out if this is something we want to consider in the very long term.
Comment 4 by, Dec 17 2014
Labels: Area-Internals
Comment 5 Deleted
Project Member Comment 6 by, Dec 1 2016
Project Member Comment 7 by, Jan 11 2017
Owner: ----
Status: Untriaged
Moving back to triage since no meaningful updates have happened since more than a year ago. Is this still a relevant issue?
Project Member Comment 8 by, Sep 27
Ping for triaging.
Sign in to add a comment