【问题标题】:DRD reports "conflicting load" error on std::mutex::lockDRD 在 std::mutex::lock 上报告“冲突加载”错误
【发布时间】:2020-01-13 15:50:11
【问题描述】:

考虑以下代码:

#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)

这是如何初始化静态结构的问题吗?我认为这是一个误报,因为静态对象的初始化应该是线程安全的。有什么办法可以消除这个错误?

注意: 现在,当我删除 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

【问题讨论】:

  • 可能与尝试同时初始化static counter manager; 的多个线程有关,但标准要求这样做是安全的。我看不出这里显示的代码有任何明显错误。
  • 哇,这听起来很不对劲。这是哪个版本的 GCC,在哪个平台上?
  • @LightnessRacesBY-SA3.0 我已经用编译器和 valgrind 的版本更新了这个问题(见问题的底部)。
  • clang++ 8.0 也会发生。默认构造函数和在产生线程之前在main 中调用get_counter 都消除了错误。使用 -fsanitize=thread 不会给出任何警告。 Valgrind 的helgrind 工具也不会报错。

标签: c++ multithreading c++11 valgrind


【解决方案1】:

已确认是一个 drd 错误,应该已经在 drd master 上修复: https://bugs.kde.org/show_bug.cgi?id=416286

【讨论】:

    猜你喜欢
    • 2015-08-24
    • 1970-01-01
    • 2017-03-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-08-24
    相关资源
    最近更新 更多