Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gstreamer gstreamer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 939
    • Issues 939
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 443
    • Merge requests 443
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gstreamergstreamer
  • Issues
  • #677
Closed
Open
Issue created Mar 25, 2021 by Pieter Jordaan@rompelstompel

systemclock: Deadlock caused by possible regression

Hi

I discovered a deadlock scenario in systemclock introduced by @bilboed commit 17feeb1b

The code in line 972 makes the assumption that the end time in the absolute sleep is from the MONOTONIC clock. When the pipeline is set to use REALTIME (or something else), however, the sleep never wakes (in this lifetime), causing sync items to deadlock.

In my test case

{tv_sec = 1616671370, tv_nsec = 913332245}

was the end time waited on, but my monotonic clock (minutes later) was at tv_sec = 617953.

I see the following possible fixes/workarounds

  1. Don't set the pipeline to REALTIME and manually do the realtime calculations on my end
  2. Use the same CLOCK type to sleep for absolute time
  3. Calculate the proper MONITONIC end time, instead of the pipeline clock's end time.
  4. Skip the nanosleep optimisation when not on the MONOTONIC clock

Here is a small example I used to test my theory:

#include <ctime>
#include <iostream>
#include <time.h>

using namespace std;

int main() {
    timespec startreal, startmonotonic;
    clock_gettime(CLOCK_REALTIME, &startreal);
    clock_gettime(CLOCK_MONOTONIC, &startmonotonic);
    cout << "MONO: " << startmonotonic.tv_sec << " SYS: "  << startreal.tv_sec << endl;
    timespec end = startreal;
    end.tv_sec += 5;

    clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &end, NULL );
    clock_gettime(CLOCK_REALTIME, &startreal);
    clock_gettime(CLOCK_MONOTONIC, &startmonotonic);
    cout << "AFTERMONO: " << startmonotonic.tv_sec << " SYS: "  << startreal.tv_sec << endl;

    return 0;
}

Obviously AFTERMONO is not printed after 5s...

I'm happy to make a pull request when you recommend the correct approach to follow from my or your suggestions

Edited Mar 25, 2021 by Pieter Jordaan
Assignee
Assign to
Time tracking