GstClock time values can jump in 32-bit applications.
Submitted by Michael Rubinstein
Link to original bug (#697441)
Description
Rare clock jumps of around 4.3 seconds were seen in a 32-bit Windows application. GStreamer and the app were built with MinGW/GCC, so the problem probably applies to any 32-bit environment.
The reader/writer locks in gstclock.c guarantee consistent calibration values. However, they don't make load/stores of "last_time" atomic.
Here's where I think the problem occurs:
The value of time is close to a value that would carry from the low word to the high. Say 0x00000000 FFFFFFFF.
A thread is executing:
priv->last_time = MAX (ret, priv->last_time);
It has read the FFFFFFFF
Another thread interrupts the first and updates last_time to
0x00000001 00000000
The first thread resumes and reads the high word yielding
0x00000001 FFFFFFFF
which it stores in last_time.
Note FFFFFFFF is around 4.3 seconds in ns.
My fix is to use GST_OBJECT_LOCK/UNLOCK in place of read_seqbegin/read_seqretry. This has no measurable performance impact in my application. It seems to fix the problem, but since the problem occurs rarely, more testing is needed.
Version: 1.0.5