Why Valgrind segfaults when I launch a new thread

Question

I'm writing a program in C++ and I noticed something very odd.

When I run my program under Xcode everything works fine, but when I do that under Valgrind it gives me a segmentation fault after a few seconds.

I managed to extract a very simple code that gives me that error:

#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;
}

What I'm doing is simply building my executable under Xcode with these flags:

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

and then run the executable under Valgrind to find memory leaks. You'll see that I'm calling the Python C API because I'm using it in my main code but this code throws me the segfault without using them.

Anyway Valgrind, along with some other stuff, gives me the following output:

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

Is it possible that spawning a thread under Valgrind is the cause of the error?

P.S:
My OS is MacOS 10.12.5 and I'm using Xcode 8.3.3 and Valgrind 3.13.0.

Answer 1

Is it possible that spawning a thread under Valgrind is the cause of the error?

It appears that this is indeed a problem with Valgrind on Mac OS X when running binaries that use pthread:

Access not within mapped region in _pthread_find_thread (OS X 10.11) https://bugs.kde.org/show_bug.cgi?id=349128

Your failures with Valgrind look similar to what was reported here:

std::thread.join() SIGSEGV on Mac OS under Valgrind