Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gstreamer
gstreamer
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 405
    • Issues 405
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 80
    • Merge Requests 80
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GStreamer
  • gstreamergstreamer
  • Issues
  • #37

Closed
Open
Opened Apr 06, 2013 by Bugzilla Migration User@bugzilla-migration

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

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: gstreamer/gstreamer#37