[Bug 697441] New: GstClock time values can jump in 32-bit applications.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=697441
  GStreamer | gstreamer (core) | 1.0.5

           Summary: GstClock time values can jump in 32-bit applications.
    Classification: Platform
           Product: GStreamer
           Version: 1.0.5
        OS/Version: Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mrubinstein at weather.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.