为什么在我启动新线程时 Valgrind 会出现段错误
Why Valgrind segfaults when I launch a new thread
我正在用 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:
我的 OS 是 MacOS 10.12.5
,我正在使用 Xcode 8.3.3
和 Valgrind 3.13.0
。
Is it possible that spawning a thread under Valgrind is the cause of the error?
当 运行 使用 pthread 的二进制文件时,Mac OS X 上的 Valgrind 似乎确实存在问题:
访问不在 _pthread_find_thread 的映射区域内 (OS X 10.11)
https://bugs.kde.org/show_bug.cgi?id=349128
您的 Valgrind 失败与此处报告的相似:
std::thread.join() SIGSEGV on Mac OS under Valgrind
我在使用 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
刚发现还有一个bug跟踪https://bugs.kde.org/show_bug.cgi?id=380269。
这确实是一个历史错误。希望它不会再花 2 年才能修好。
我正在用 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:
我的 OS 是 MacOS 10.12.5
,我正在使用 Xcode 8.3.3
和 Valgrind 3.13.0
。
Is it possible that spawning a thread under Valgrind is the cause of the error?
当 运行 使用 pthread 的二进制文件时,Mac OS X 上的 Valgrind 似乎确实存在问题:
访问不在 _pthread_find_thread 的映射区域内 (OS X 10.11) https://bugs.kde.org/show_bug.cgi?id=349128
您的 Valgrind 失败与此处报告的相似:
std::thread.join() SIGSEGV on Mac OS under Valgrind
我在使用 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
刚发现还有一个bug跟踪https://bugs.kde.org/show_bug.cgi?id=380269。 这确实是一个历史错误。希望它不会再花 2 年才能修好。