DRD сообщает об ошибке «конфликтует загрузка» на std :: mutex :: lock - PullRequest
Новая
       13

DRD сообщает об ошибке «конфликтует загрузка» на std :: mutex :: lock

4 голосов
/ 13 января 2020

Рассмотрим следующий код: 

#include <mutex>
#include <thread>
#include <vector>
#include <thread>

struct counter {
    counter()
    {
    }

    size_t
    get()
    {
        std::unique_lock<std::mutex> lock(mutex);

        return 0;
    }

    std::mutex mutex;
};

static counter &
get_counter()
{
    static counter manager;
    return manager;
};

static void do_work()
{
    get_counter().get();
}

int main()
{
    std::vector<std::thread> v;
    for (int i = 0; i < 16; i++)
        v.emplace_back([]{ do_work(); });

    for (auto &t : v)
        t.join();
}

При компиляции: g++ -std=c++11 source.cpp -lpthread и запуск под Valgrind valgrind --tool=drd ./a.out Я получаю следующую ошибку: 

==4297== drd, a thread error detector
==4297== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
==4297== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==4297== Command: ./a.out
==4297== 
==4297== Thread 3:
==4297== Conflicting load by thread 3 at 0x0010f050 size 4
==4297==    at 0x4844083: vgDrd_mutex_type (drd_pthread_intercepts.c:380)
==4297==    by 0x4844083: pthread_mutex_lock_intercept (drd_pthread_intercepts.c:885)
==4297==    by 0x4844083: pthread_mutex_lock (drd_pthread_intercepts.c:898)
==4297==    by 0x109E72: __gthread_mutex_lock(pthread_mutex_t*) (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x109EC7: std::mutex::lock() (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x10A4A8: std::unique_lock<std::mutex>::lock() (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x10A206: std::unique_lock<std::mutex>::unique_lock(std::mutex&) (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x10A0C4: counter::get() (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x10940B: do_work() (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x109420: main::{lambda()#1}::operator()() const (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x109E06: void std::__invoke_impl<void, main::{lambda()#1}>(std::__invoke_other, main::{lambda()#1}&&) (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x109DA7: std::__invoke_result<main::{lambda()#1}>::type std::__invoke<main::{lambda()#1}>(std::__invoke_result&&, (main::{lambda()#1}&&)...) (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x109D45: void std::thread::_Invoker<std::tuple<main::{lambda()#1}> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297==    by 0x109D06: std::thread::_Invoker<std::tuple<main::{lambda()#1}> >::operator()() (in /home/igchor/Projects/libpmemobj-cpp/build/a.out)
==4297== Allocation context: BSS section of /home/igchor/Projects/libpmemobj-cpp/build/a.out
==4297== Other segment start (thread 2)
==4297==    (thread finished, call stack no longer available)
==4297== Other segment end (thread 2)
==4297==    (thread finished, call stack no longer available)
==4297== 
==4297== 
==4297== For lists of detected and suppressed errors, rerun with: -s
==4297== ERROR SUMMARY: 15 errors from 1 contexts (suppressed: 20 from 12)

Это какая-то проблема с тем, как stati c структуры инициализированы? Я предполагаю, что это ложноположительный результат, так как инициализация объектов stati c должна быть поточно-ориентированной. Есть ли способ заставить эту ошибку замолчать?

Примечание: Теперь, когда я удаляю конструктор структуры counter, это выглядит так: 

struct counter {
    size_t
    get()
    {
        std::unique_lock<std::mutex> lock(mutex);

        return 0;
    }

    std::mutex mutex;
};

drd не сообщает об ошибках.

Я тестировал все это на Ubuntu 19.10 с:

  • g ++ - 9.2.1 (и clang ++ 9.0.0)
  • Valgrind 3,15

1 Ответ

0 голосов
/ 16 января 2020

Было подтверждено, что это ошибка drd, и она уже должна быть исправлена ​​на drd master: https://bugs.kde.org/show_bug.cgi?id=416286

...