Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ThreadSanitizer: signal-unsafe call inside of a signal #147

Closed
cyyever opened this issue Aug 30, 2018 · 8 comments
Closed

ThreadSanitizer: signal-unsafe call inside of a signal #147

cyyever opened this issue Aug 30, 2018 · 8 comments

Comments

@cyyever
Copy link
Contributor

cyyever commented Aug 30, 2018

When I use doctest with ThreadSanitizer,it reports the following error:

> 
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=2367)
    #0 operator new(unsigned long) <null> (TSAN_faiss_test+0x4d980a)
    #1 __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/ext/new_allocator.h:111:27 (TSAN_faiss_test+0x513714)
    #2 std::allocator_traits<std::allocator<char> >::allocate(std::allocator<char>&, unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/alloc_traits.h:436:20 (TSAN_faiss_test+0x5135d7)
    #3 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/basic_string.tcc:153:14 (TSAN_faiss_test+0x51336c)
    #4 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/basic_string.tcc:219:14 (TSAN_faiss_test+0x5342a4)
    #5 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/basic_string.h:236:11 (TSAN_faiss_test+0x534148)
    #6 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/basic_string.h:255:4 (TSAN_faiss_test+0x5340b8)
    #7 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/bits/basic_string.h:511:9 (TSAN_faiss_test+0x5055cc)
    #8 doctest::(anonymous namespace)::FatalConditionHandler::handleSignal(int) /usr/local/include/doctest/doctest.h:4026:32 (TSAN_faiss_test+0x4fb2e6)
    #9 __tsan::CallUserSignalHandler(__tsan::ThreadState*, bool, bool, bool, int, __sanitizer::__sanitizer_siginfo*, void*) <null> (TSAN_faiss_test+0x43de93)

> 

Usually the signal handle code should be as simple as possible to avoid non signal-safe calls, so I suggest to refactor this code.

@cyyever
Copy link
Contributor Author

cyyever commented Aug 30, 2018

The version is doctest 2.0.0.

@onqtam
Copy link
Member

onqtam commented Aug 30, 2018

I'll have to think about this. In the meantime I would suggest suppressing TSAN errors from that code part.

@cyyever
Copy link
Contributor Author

cyyever commented Aug 30, 2018

A simple workaround may be to use std::atomic<std::string> in signal handler?

@onqtam
Copy link
Member

onqtam commented Aug 30, 2018

I think the issue will not be solved with atomic strings - I think the problem is that there are allocations which may throw and its not just because of std::string - I use also streams (think std::ostream ).

Anyway I won't be able to attend to this in the near future... but I'm keeping it open

@cyyever
Copy link
Contributor Author

cyyever commented Aug 31, 2018

I will try to fix this,and then give a PR.

cyyever added a commit to DEEPIR/doctest that referenced this issue Sep 4, 2018
onqtam added a commit that referenced this issue Sep 4, 2018
@onqtam
Copy link
Member

onqtam commented Nov 29, 2018

any news on this?

@onqtam
Copy link
Member

onqtam commented Nov 30, 2018

I'll go ahead and close it - until something more comes up.

@onqtam onqtam closed this as completed Nov 30, 2018
@PushyBish
Copy link

This seems to not be fully resolved yet. (Version 2.3.6)

WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=75273)
    #0 operator new[](unsigned long) <null> (libtsan.so.0+0x745ba)
    #1 doctest::String::String(char const*, unsigned int) ***/include/doctest/doctest.h:3035 (test-withlog+0x4296b3)
    #2 doctest::String::String(char const*) ***/include/doctest/doctest.h:3025 (test-withlog+0x4295bb)
    #3 reportFatal ***/include/doctest/doctest.h:4087 (test-withlog+0x42e8ac)
    #4 handleSignal ***/include/doctest/doctest.h:4020 (test-withlog+0x42e3c2)
    #5 <null> <null> (libtsan.so.0+0x28da3)
    #6 __gnu_cxx::__verbose_terminate_handler() <null> (libstdc++.so.6+0x607d4)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal (/lib64/libtsan.so.0+0x745ba) in operator new[](unsigned long)
==================
==================
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=75273)
    #0 operator delete[](void*) <null> (libtsan.so.0+0x7488d)
    #1 doctest::String::~String() ***/include/doctest/doctest.h:3021 (test-withlog+0x429575)
    #2 doctest::TestCaseException::~TestCaseException() ***/include/doctest/doctest.h:1630 (test-withlog+0x441ea7)
    #3 reportFatal ***/doctest/doctest.h:4087 (test-withlog+0x42e8d8)
    #4 handleSignal ***/doctest/doctest.h:4020 (test-withlog+0x42e3c2)
    #5 <null> <null> (libtsan.so.0+0x28da3)
    #6 __gnu_cxx::__verbose_terminate_handler() <null> (libstdc++.so.6+0x607d4)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal (/lib64/libtsan.so.0+0x7488d) in operator delete[](void*)

I believe this is due to the const char*-change of this issue is being converted to const std::string&
and on to doctest::String, which, for long messages, means heap allocations.

I will try to fix this,and then give a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants