logo标签列表

为什么我启动一个新线程时Valgrind会导致分段错误

c++multithreadingsegmentation-faultvalgrind
9
我正在使用C++编写程序，发现了一些奇怪的问题。当我在Xcode下运行程序时一切正常，但是在Valgrind下运行几秒钟后就会出现“段错误（segmentation fault）”。我已经提取了一个非常简单的代码，也会出现这个错误：
#include <thread>

void exec_1() {}

int main(int argc, const char * argv[]) {

    std::thread simulator_thread;
    simulator_thread = std::thread(exec_1);
    simulator_thread.join();

    return 0;
}

我是一个有用的助手，可以翻译文本。
我正在做的事情只是使用以下标志在Xcode下构建我的可执行文件：
CFLAGS:
-I/usr/local/lib/python3.6/site-packages/numpy/core/include
-I/usr/local/Cellar/python3/3.6.1/Frameworks/Python.framework/Versions/3.6/include/python3.6m 
-Wno-unused-result -Wsign-compare -Wunreachable-code
-fno-common -dynamic -DNDEBUG -g -fwrapv -Wall -Wstrict-prototypes

LDFLAGS:
-L/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/config-3.6m-darwin
-lpython3.6m -ldl -framework CoreFoundation

然后在Valgrind下运行可执行文件以查找内存泄漏。你会看到我正在调用Python C API，因为我正在我的main代码中使用它，但是即使不使用它，这段代码也会抛出segfault。

无论如何，Valgrind还提供了其他一些信息，输出如下：

Thread 2:
==41660== Invalid read of size 4
==41660==    at 0x1016FA899: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==41660==    by 0x1016FA886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==41660==    by 0x1016FA08C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==41660==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==41660== 
==41660== 
==41660== Process terminating with default action of signal 11 (SIGSEGV)
==41660==  Access not within mapped region at address 0x18
==41660==    at 0x1016FA899: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==41660==    by 0x1016FA886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==41660==    by 0x1016FA08C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==41660==  If you believe this happened as a result of a stack
==41660==  overflow in your program's main thread (unlikely but
==41660==  possible), you can try to increase the size of the
==41660==  main thread stack using the --main-stacksize= flag.
==41660==  The main thread stack size used in this run was 8388608.
--41660:0:schedule VG_(sema_down): read returned -4

可能在Valgrind下创建线程是错误的原因吗？

P.S:
我的操作系统是MacOS 10.12.5，我正在使用Xcode 8.3.3和Valgrind 3.13.0。

如果在CFLAGS和LDFLAGS中添加-pthread标志，是否会有任何区别？ - nos
虽然这与您的问题无关，但几乎总是应优先选择初始化而非赋值。例如：std::thread simulator_thread( exec_1); - user2100815
@NeilButterworth 你说得对。但是在我的主程序中，我通过创建一个空的std::thread数组并使用for循环为它们分配真实对象来生成多个线程。在这里，我尝试尽可能地保持结构与我的主要代码接近。 - jackscorrow
@nos 不会改变任何东西。 - jackscorrow
你解决了吗？我也遇到了同样的问题。 - j b
@JamieBullock 不好意思:( 我没能解决问题，所以我不再使用Valgrind了。 - jackscorrow
2个回答
8
1
我看到这是一个相当古老的 bug。希望他们能尽快修复它。谢谢！ - jackscorrow
仍未修复 :( - Alex
4
我在使用macOS 10.12.6和Valgrind 3.13.0时仍然面临着同样的问题。
==82699== Process terminating with default action of signal 11 (SIGSEGV)
==82699==  Access not within mapped region at address 0x18
==82699==    at 0x10058E899: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==82699==    by 0x10058E886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==82699==    by 0x10058E08C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==82699==  If you believe this happened as a result of a stack
==82699==  overflow in your program's main thread (unlikely but
==82699==  possible), you can try to increase the size of the
==82699==  main thread stack using the --main-stacksize= flag.
==82699==  The main thread stack size used in this run was 8388608.
--82699:0:schedule VG_(sema_down): read returned -4
==82699== 
==82699== Events    : Ir
==82699== Collected : 30468496
==82699== 
==82699== I   refs:      30,468,496
Segmentation fault: 11

刚刚发现还有一个错误跟踪：https://bugs.kde.org/show_bug.cgi?id=380269。这真的是一个历史性的错误。希望不需要再等两年才能修复。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接