[Linux] Frame data corruption (fork-exec?)

Ask software engineering and SDK questions for developers working on Mac OS X, Windows or Linux.
  • Author
  • Message
Offline

kurz_trackmen

  • Posts: 3
  • Joined: Wed May 09, 2018 11:25 am
  • Real Name: Christian Kurz

[Linux] Frame data corruption (fork-exec?)

PostWed May 09, 2018 12:04 pm

Hello,

We are seeing some issues with occasional frame data corruption (parts of previous images overlaid over the current frame).

While debugging we found that we could reliably reproduce a similar issue by having a thread unrelated to the data capturing thread run external commands through QProcess or std::system (which made us think that the issue might probably be caused by an interaction with fork-exec).

Here is a patch to get from the Capture SDK example to a minimal version that exhibits the problem:

Code: Select all
diff -upr Capture_orig/Capture.cpp Capture/Capture.cpp
--- Capture_orig/Capture.cpp   2018-05-09 13:26:46.099198138 +0200
+++ Capture/Capture.cpp   2018-05-09 12:50:09.249131744 +0200
@@ -25,6 +25,9 @@
 ** -LICENSE-END-
 */
 
+#include <atomic>
+#include <thread>
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -222,6 +225,16 @@ int main(int argc, char *argv[])
    signal(SIGTERM, sigfunc);
    signal(SIGHUP, sigfunc);
 
+  std::atomic_bool terminate{false};
+
+  auto sleeper = std::thread([&terminate]
+    {
+      while (!terminate)
+      {
+        std::system("/bin/usleep 1000");
+      }
+    });
+
    // Process the command line arguments
    if (!g_config.ParseArguments(argc, argv))
    {
@@ -392,6 +405,13 @@ int main(int argc, char *argv[])
    }
 
 bail:
+  terminate = true;
+
+  if (sleeper.joinable())
+  {
+    sleeper.join();
+  }
+
    if (g_videoOutputFile != 0)
       close(g_videoOutputFile);
 
diff -upr Capture_orig/Makefile Capture/Makefile
--- Capture_orig/Makefile   2018-05-09 13:26:46.099198138 +0200
+++ Capture/Makefile   2018-05-09 12:42:59.278492081 +0200
@@ -25,8 +25,8 @@
 #** -LICENSE-END-
 
 CC=g++
-SDK_PATH=../../include
-CFLAGS=-Wno-multichar -I $(SDK_PATH) -fno-rtti
+SDK_PATH=/usr/include/blackmagic/
+CFLAGS=-std=c++11 -Wno-multichar -I $(SDK_PATH) -fno-rtti
 LDFLAGS=-lm -ldl -lpthread
 
 Capture: Capture.cpp Config.cpp $(SDK_PATH)/DeckLinkAPIDispatch.cpp


When raw video is captured by the above version of Capture (200 frames are more than sufficient to examine the behaviour), a significant number of frames are corrupted, appearing predominantly green and overlaid with parts of previous frames. The problem becomes more apparent when the camera is in motion.

Is there any known interaction between the driver and std::system/fork-exec?
Is there a workaround or other way to mitigate this issue?

Some additional information:
Linux: openSUSE 13.2 (Harlequin) (x86_64)
Kernel: 3.16.6-2-desktop
Driver: desktopvideo-10.9.12

Best regards,
Christian Kurz
Offline

Cameron Nichols

Blackmagic Design

  • Posts: 442
  • Joined: Mon Sep 04, 2017 4:05 am

Re: [Linux] Frame data corruption (fork-exec?)

PostThu May 17, 2018 12:13 am

Hi Kurz,

Thanks for providing this sample. This issue has been lodged and I will update you with release plans for the fix.

Regards
Cameron
Offline

kurz_trackmen

  • Posts: 3
  • Joined: Wed May 09, 2018 11:25 am
  • Real Name: Christian Kurz

Re: [Linux] Frame data corruption (fork-exec?)

PostFri May 18, 2018 9:49 am

Hi Cameron,

Thank you! Please let us know if you need any additional information!

Best,
Christian
Offline

kurz_trackmen

  • Posts: 3
  • Joined: Wed May 09, 2018 11:25 am
  • Real Name: Christian Kurz

Re: [Linux] Frame data corruption (fork-exec?)

PostFri Jun 22, 2018 7:29 am

Hi Cameron,

Do you have any updates on this issue?

Best,
Christian
Offline

Steinar H. Gunderson

  • Posts: 70
  • Joined: Fri Aug 14, 2015 12:17 pm

Re: [Linux] Frame data corruption (fork-exec?)

PostTue Jul 03, 2018 2:38 pm

kurz_trackmen wrote:Hello,
Is there any known interaction between the driver and std::system/fork-exec?


In general, fork/exec in a multithreaded program is extremely hard to get right (much worse than people assume), so I'm not surprised if there are issues here. It's probably better to design your program not to require it if you can.

Return to Software Developers

Who is online

Users browsing this forum: No registered users and 26 guests