Thread Sanitizer Issues

C++
1

Hi there,

I am trying to run thread sanitizer on my program and running into issues reported down in the guts of opencv. I have recreated a minimal example below. Note that I am running opencv 3.4.1, and it is not currently feasible to upgrade.

Is this an actual warning I should be concerned about, or can I suppress it? Thanks for any insight.

Here is the example that creates the thread sanitizer warning. If I don’t wrap the clahe test in a for loop, I can still get the warnings to be reported, they just occur much less frequently.

#include <opencv2/core.hpp>
#include <opencv2/imgproc.hpp>

int main(int argc, char* argv[])
{
  for (size_t i = 0; i < 100; i++)
  {
    cv::Mat img = cv::Mat::zeros(500, 500, CV_16U);
    cv::Ptr<cv::CLAHE> clahe = cv::createCLAHE();
    clahe->apply(img, img);
  }
  return 0;
}

Here is the thread sanitizer warning:

==================
WARNING: ThreadSanitizer: data race (pid=22082)
  Write of size 8 at 0x007faf103b00 by thread T6:
    #0 operator delete(void*) <null> (libtsan.so.0+0x799db)
    #1 cv::detail::PtrOwnerImpl<cv::ParallelJob, cv::DefaultDeleter<cv::ParallelJob> >::deleteSelf() <null> (libopencv_core.so.3.4+0x1c9c9f)

  Previous write of size 8 at 0x007faf103b00 by main thread (mutexes: write M132):
    #0 operator new(unsigned long) <null> (libtsan.so.0+0x796b3)
    #1 cv::ThreadPool::run(cv::Range const&, cv::ParallelLoopBody const&, double) <null> (libopencv_core.so.3.4+0x1ccb8f)
    #2 __libc_start_main <null> (libc.so.6+0x206df)

  Mutex M132 (0x007fae302dc8) created at:
    #0 pthread_mutex_init <null> (libtsan.so.0+0x30027)
    #1 cv::ThreadPool::ThreadPool() <null> (libopencv_core.so.3.4+0x1cb963)
    #2 __libc_start_main <null> (libc.so.6+0x206df)

  Thread T6 (tid=22089, running) created by main thread at:
    #0 pthread_create <null> (libtsan.so.0+0x2f6d7)
    #1 cv::WorkerThread::WorkerThread(cv::ThreadPool&, unsigned int) <null> (libopencv_core.so.3.4+0x1caeaf)
    #2 __libc_start_main <null> (libc.so.6+0x206df)

SUMMARY: ThreadSanitizer: data race (/usr/lib/aarch64-linux-gnu/libtsan.so.0+0x799db) in operator delete(void*)
==================
==================
WARNING: ThreadSanitizer: data race (pid=22082)
  Write of size 8 at 0x007fb58005a0 by thread T6:
    #0 operator delete(void*) <null> (libtsan.so.0+0x799db)
    #1 cv::WorkerThread::thread_body() <null> (libopencv_core.so.3.4+0x1ca717)

  Previous write of size 8 at 0x007fb58005a0 by main thread (mutexes: write M132):
    #0 operator new(unsigned long) <null> (libtsan.so.0+0x796b3)
    #1 cv::ThreadPool::run(cv::Range const&, cv::ParallelLoopBody const&, double) <null> (libopencv_core.so.3.4+0x1ccbdb)
    #2 __libc_start_main <null> (libc.so.6+0x206df)

  Mutex M132 (0x007fae302dc8) created at:
    #0 pthread_mutex_init <null> (libtsan.so.0+0x30027)
    #1 cv::ThreadPool::ThreadPool() <null> (libopencv_core.so.3.4+0x1cb963)
    #2 __libc_start_main <null> (libc.so.6+0x206df)

  Thread T6 (tid=22089, running) created by main thread at:
    #0 pthread_create <null> (libtsan.so.0+0x2f6d7)
    #1 cv::WorkerThread::WorkerThread(cv::ThreadPool&, unsigned int) <null> (libopencv_core.so.3.4+0x1caeaf)
    #2 __libc_start_main <null> (libc.so.6+0x206df)

SUMMARY: ThreadSanitizer: data race (/usr/lib/aarch64-linux-gnu/libtsan.so.0+0x799db) in operator delete(void*)
==================
ThreadSanitizer: reported 2 warnings
1 Like
2

I suspect that you need different source and destination Mats.

3

Thanks Matti,

I have the same issue when using different source/destinations:

#include <opencv2/core.hpp>
#include <opencv2/imgproc.hpp>

int main(int argc, char* argv[])
{
  for (size_t i = 0; i < 100; i++)
  {
    cv::Mat img1 = cv::Mat::zeros(500, 500, CV_16U);
    cv::Mat img2;
    cv::Ptr<cv::CLAHE> clahe = cv::createCLAHE();
    clahe->apply(img1, img2);
  }
  return 0;
}
4

those kinds of tools love to flag a lot of things that can’t be proven safe (but are safe in practice) because the source doesn’t contain enough information to produce a proof.

maybe open an issue on the github. I’m not saying it’s necessarily gonna lead anywhere. if you can gather further evidence that would be good. I don’t know whether this tool provides strong evidence for bugs or it’s just complaining about something it can’t comprehend.

if you particularly care about this issue, please dig into the source of that CLAHE thing and see if anything catches your eye.