Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0x70000324543E at 0x10042E42A: _pthread_find_thread (in /usr/lib/system/libsystem_pthread.dylib) by 0x100430CE8: _pthread_lookup_thread (in /usr/lib/system/libsystem_pthread.dylib) by 0x100430AC0: pthread_join (in /usr/lib/system/libsystem_pthread.dylib) by 0x100000C75: child_fn_1 (threadname.c:51) by 0x10042FCC2: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib) by 0x10042FC3F: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib) by 0x10042CDA4: thread_start (in /usr/lib/system/libsystem_pthread.dylib) If you believe this happened as a result of a stack overflow in your program's main thread (unlikely but possible), you can try to increase the size of the main thread stack using the --main-stacksize= flag. The main thread stack size used in this run was 8388608. :0:schedule VG_(sema_down): read returned -4 Memcheck: mc_leakcheck.c:1045 (void lc_scan_memory(Addr, SizeT, Bool, Int, Int, Addr, SizeT)): Assertion 'bad_scanned_addr >= VG_ROUNDUP(start, sizeof(Addr))' failed. Reproducible: Always Steps to Reproduce: 1. Apply preliminary patch set from bz#348909 2. $ ./autogen.sh 3. $ ./configure 4. $ make 5. $ make check 6. $ perl tests/vg_regtest memcheck/tests/err_disable3 memcheck/tests/threadname memcheck/tests/threadname_xml Actual Results: $ perl tests/vg_regtest memcheck/tests/err_disable3 memcheck/tests/threadname memcheck/tests/threadname_xml err_disable3: valgrind -q ./err_disable3 sh: line 1: 15976 Segmentation fault: 11 VALGRIND_LIB=/Users/usera/Coding/valgrind/.in_place VALGRIND_LIB_INNER=/Users/usera/Coding/valgrind/.in_place /Users/usera/Coding/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=memcheck -q ./err_disable3 > err_disable3.stdout.out 2> err_disable3.stderr.out *** err_disable3 failed (stderr) *** threadname: valgrind -q ./threadname sh: line 1: 16020 Killed: 9 VALGRIND_LIB=/Users/usera/Coding/valgrind/.in_place VALGRIND_LIB_INNER=/Users/usera/Coding/valgrind/.in_place /Users/usera/Coding/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=memcheck -q ./threadname > threadname.stdout.out 2> threadname.stderr.out *** threadname failed (stderr) *** threadname_xml: valgrind --xml=yes --xml-fd=2 --log-file=/dev/null ./threadname *** threadname_xml failed (stderr) *** == 3 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable3 (stderr) memcheck/tests/threadname (stderr) memcheck/tests/threadname_xml (stderr) Expected Results: No regression test failures.
I'm able to reproduce this on valgrind-3.12.0.SVN (r15723).
*** Bug 363123 has been marked as a duplicate of this bug. ***
Is this a valgrind bug or a bug of pthread library on os x? This webpage (https://bytecoin.org/blog/pthread-bug-osx/) explains it as if it is an apple bug. Nevertheless, do you have any time estimation for us to be able to use valgrind with a multithreaded code on os x? Thank you.
That link seems to be dead now. Archived link: https://web.archive.org/web/20160304041047/https://bytecoin.org/blog/pthread-bug-osx
I'd say a Valgrind issue. Still happening on macOS 10.13.