Update folly/ScopeGuard.h Fixed spelling error in comment. #9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
The comment is correct. "iff" means "if and only if", see http://en.wikipedia.org/wiki/If_and_only_if |
ghost
pushed a commit
that referenced
this pull request
May 30, 2016
Summary: Diff #9 of 14. Reviewed By: mzlee Differential Revision: D3262436 fbshipit-source-id: 60c5df03e91163c651bc6e5e0d38ba8b46b8c723
Closed
Closed
facebook-github-bot
pushed a commit
that referenced
this pull request
Mar 31, 2017
Summary:
ubsan flags this problem:
```
buck-out/opt-ubsan/gen/folly/__default_headers__#header-mode-symlink-tree-with-header-map,headers/folly/experimental/StringKeyedCommon.h:31:18: runtime error: null pointer passed as argument 2, which is declared to never be null
third-party-buck/gcc-4.9-glibc-2.20-fb/build/glibc/include/string.h:47:28: note: nonnull attribute specified here
#0 0x5cb88f in std::pair<std::__detail::_Node_iterator<std::pair<folly::Range<char const*> const, facebook::eden::GitIgnore>, false, true>, bool> folly::StringKeyedUnorderedMap<facebook::eden::GitIgnore, folly::Hash, std::equal_to<folly::Range<char const*> >, std::allocator<std::pair<folly::Range<char const*> const, facebook::eden::GitIgnore> > >::emplace<facebook::eden::GitIgnore>(folly::Range<char const*>, facebook::eden::GitIgnore&&) buck-out/opt-ubsan/gen/folly/__default_headers__#header-mode-symlink-tree-with-header-map,headers/folly/experimental/StringKeyedCommon.h:31
#1 0x5c6652 in facebook::eden::(anonymous namespace)::IgnoreChecker::isIgnored(facebook::eden::detail::RelativePathBase<folly::Range<char const*> >) eden/fs/inodes/Dirstate.cpp:226
#2 0x5c6037 in facebook::eden::(anonymous namespace)::IgnoreChecker::isIgnored(facebook::eden::detail::RelativePathBase<folly::Range<char const*> >) eden/fs/inodes/Dirstate.cpp:180
#3 0x5c5173 in facebook::eden::Dirstate::getStatusForExistingDirectory(facebook::eden::detail::RelativePathBase<folly::Range<char const*> >) const eden/fs/inodes/Dirstate.cpp:372
#4 0x5c4509 in facebook::eden::Dirstate::getStatus() const eden/fs/inodes/Dirstate.cpp:272
#5 0x50a448 in verifyExpectedDirstate(facebook::eden::Dirstate const*, std::unordered_map<std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, std::fbstring_core<char> >, facebook::eden::StatusCode, std::hash<std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, std::fbstring_core<char> > >, std::equal_to<std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, std::fbstring_core<char> > >, std::allocator<std::pair<std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, std::fbstring_core<char> > const, facebook::eden::StatusCode> > >&&) eden/fs/inodes/test/DirstateTest.cpp:48
#6 0x50c70c in Dirstate_addDirectoriesWithMixOfFiles_Test::TestBody() eden/fs/inodes/test/DirstateTest.cpp:220
#7 0xb45857 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /home/engshare/third-party2/gtest/1.7.0/src/gtest-1.7.0/./src/gtest.cc:2364
#8 0xb36784 in testing::Test::Run() /home/engshare/third-party2/gtest/1.7.0/src/gtest-1.7.0/./src/gtest.cc:2437
#9 0xb36957 in testing::TestInfo::Run() [clone .part.558] /home/engshare/third-party2/gtest/1.7.0/src/gtest-1.7.0/./src/gtest.cc:2612
#10 0xb36b74 in testing::TestCase::Run() [clone .part.559] /home/engshare/third-party2/gtest/1.7.0/src/gtest-1.7.0/./src/gtest.cc:2587
#11 0xb3806e in testing::internal::UnitTestImpl::RunAllTests() [clone .part.561] /home/engshare/third-party2/gtest/1.7.0/src/gtest-1.7.0/./src/gtest.cc:4571
#12 0xb382d9 in testing::UnitTest::Run() /home/engshare/third-party2/gtest/1.7.0/src/gtest-1.7.0/./src/gtest.cc:4519
#13 0x861ca7 in main third-party-buck/gcc-4.9-glibc-2.20-fb/build/gtest/include/gtest/gtest.h:2326
#14 0x7f20be0740f5 in __libc_start_main /home/engshare/third-party2/glibc/2.20/src/glibc-2.20/csu/libc-start.c:289
#15 0x4a552c in _start /home/engshare/third-party2/glibc/2.20/src/glibc-2.20/csu/../sysdeps/x86_64/start.S:122
UndefinedBehaviorSanitizer: undefined-behavior buck-out/opt-ubsan/gen/folly/__default_headers__#header-mode-symlink-tree-with-header-map,headers/folly/experimental/StringKeyedCommon.h:31:18
```
The issue is that `StringPiece` default constructs to `{nullptr, nullptr}` as a valid representation of an empty string.
This is tripping up UBSAN in this case.
The fix is a trivial nullptr check
Reviewed By: igorsugak
Differential Revision: D4791015
fbshipit-source-id: dec7484b29ecb29c17b8dd6a9b0e8093f07d63cb
facebook-github-bot
pushed a commit
that referenced
this pull request
Oct 4, 2018
Summary:
TSAN flagged the following lock inversion below. The reason for this lock inversion
is because of the following example usage:
1. set request context B, save old one A (lock B, lock A)
2. later on, reset request context back to A, get the old one back B (lock A, lock B)
In the two calls, we always locked the the new context first, resulting
in a lock inversion. The fix is to always acquire them in a consistent
order using `folly::acquireLocked`
TSAN report:
```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=1574307)
Cycle in lock order graph: M159 (0x7b1400000138) => M157 (0x7b14000000e8) => M159
Mutex M157 acquired here while holding mutex M159 in main thread:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
#7 0x1c7530 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:243
#8 0x36a7b in folly::RequestContext::create() ./folly/io/async/Request.h:119
#9 0x34916 in RequestContextScopeGuard ./folly/io/async/Request.h:269
Mutex M159 previously acquired by the same thread here:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
#7 0x1c7516 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:242
#8 0x36a7b in folly::RequestContext::create() ./folly/io/async/Request.h:119
#9 0x34916 in RequestContextScopeGuard ./folly/io/async/Request.h:269
Mutex M159 acquired here while holding mutex M157 in main thread:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
#7 0x1c7530 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:243
#8 0x34b99 in ~RequestContextScopeGuard ./folly/io/async/Request.h:278
Mutex M157 previously acquired by the same thread here:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
#7 0x1c7516 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:242
#8 0x34b99 in ~RequestContextScopeGuard ./folly/io/async/Request.h:278
```
Reviewed By: igorsugak
Differential Revision: D9797715
fbshipit-source-id: a0f991ae0ec8f3e9d33af6e05db49eceaf3a5174
sandraiser
pushed a commit
to sandraiser/folly
that referenced
this pull request
Mar 4, 2019
Summary:
TSAN flagged the following lock inversion below. The reason for this lock inversion
is because of the following example usage:
1. set request context B, save old one A (lock B, lock A)
2. later on, reset request context back to A, get the old one back B (lock A, lock B)
In the two calls, we always locked the the new context first, resulting
in a lock inversion. The fix is to always acquire them in a consistent
order using `folly::acquireLocked`
TSAN report:
```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=1574307)
Cycle in lock order graph: M159 (0x7b1400000138) => M157 (0x7b14000000e8) => M159
Mutex M157 acquired here while holding mutex M159 in main thread:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
facebook#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
facebook#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
facebook#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
facebook#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
facebook#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
facebook#7 0x1c7530 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:243
facebook#8 0x36a7b in folly::RequestContext::create() ./folly/io/async/Request.h:119
facebook#9 0x34916 in RequestContextScopeGuard ./folly/io/async/Request.h:269
Mutex M159 previously acquired by the same thread here:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
facebook#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
facebook#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
facebook#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
facebook#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
facebook#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
facebook#7 0x1c7516 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:242
facebook#8 0x36a7b in folly::RequestContext::create() ./folly/io/async/Request.h:119
facebook#9 0x34916 in RequestContextScopeGuard ./folly/io/async/Request.h:269
Mutex M159 acquired here while holding mutex M157 in main thread:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
facebook#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
facebook#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
facebook#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
facebook#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
facebook#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
facebook#7 0x1c7530 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:243
facebook#8 0x34b99 in ~RequestContextScopeGuard ./folly/io/async/Request.h:278
Mutex M157 previously acquired by the same thread here:
#0 0x48f18c in AnnotateRWLockAcquired ??:?
#1 0x315495 in folly::SharedMutexImpl<false, void, std::atomic, false>::lock_shared() ./folly/SharedMutex.h:385
facebook#2 0x1b0eb8 in folly::detail::LockTraitsImpl<folly::SharedMutexImpl<false, void, std::atomic, false>, (folly::detail::MutexLevel)1, false>::lock_shared(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:157
facebook#3 0x1b0e68 in std::integral_constant<bool, true> folly::LockPolicyShared::lock<folly::SharedMutexImpl<false, void, std::atomic, false> >(folly::SharedMutexImpl<false, void, std::atomic, false>&) ./folly/LockTraits.h:493
facebook#4 0x1d63a9 in LockedPtrBase ./folly/Synchronized.h:1026
facebook#5 0x1d6258 in LockedPtr ./folly/Synchronized.h:1326
facebook#6 0x1c9a17 in folly::SynchronizedBase<folly::Synchronized<folly::RequestContext::State, folly::SharedMutexImpl<false, void, std::atomic, false> >, (folly::detail::MutexLevel)1>::rlock() const ./folly/Synchronized.h:123
facebook#7 0x1c7516 in folly::RequestContext::setContext(std::shared_ptr<folly::RequestContext>) ./folly/io/async/Request.cpp:242
facebook#8 0x34b99 in ~RequestContextScopeGuard ./folly/io/async/Request.h:278
```
Reviewed By: igorsugak
Differential Revision: D9797715
fbshipit-source-id: a0f991ae0ec8f3e9d33af6e05db49eceaf3a5174
facebook-github-bot
pushed a commit
that referenced
this pull request
Dec 18, 2019
Summary: Exposed by UBSAN's unsigned-integer-overflow: ``` > folly/experimental/observer/detail/Core.cpp:179:9: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long') > #0 0x7f605837dfea in folly::observer_detail::Core::removeStaleDependents()::$_4::operator()(std::vector<std::weak_ptr<folly::observer_detail::Core>, std::allocator<std::weak_ptr<folly::observer_detail::Core> > >&) const folly/experimental/observer/detail/Core.cpp:179 > #1 0x7f6058344b0c in auto folly::SynchronizedBase<folly::Synchronized<std::vector<std::weak_ptr<folly::observer_detail::Core>, std::allocator<std::weak_ptr<folly::observer_detail::Core> > >, folly::SharedMutexImpl<false, void, std::atomic, false, false> >, (folly::detail::MutexLevel)1>::withWLock<folly::observer_detail::Core::removeStaleDependents()::$_4>(folly::observer_detail::Core::removeStaleDependents()::$_4&&) folly/Synchronized.h:210 > #2 0x7f6058344917 in folly::observer_detail::Core::removeStaleDependents() folly/experimental/observer/detail/Core.cpp:174 > #3 0x7f60583785cb in folly::observer_detail::Core::~Core()::$_2::operator()(std::unordered_set<std::shared_ptr<folly::observer_detail::Core>, std::hash<std::shared_ptr<folly::observer_detail::Core> >, std::equal_to<std::shared_ptr<folly::observer_detail::Core> >, std::allocator<std::shared_ptr<folly::observer_detail::Core> > > const&) const folly/experimental/observer/detail/Core.cpp:156 > #4 0x7f6058343cdc in auto folly::SynchronizedBase<folly::Synchronized<std::unordered_set<std::shared_ptr<folly::observer_detail::Core>, std::hash<std::shared_ptr<folly::observer_detail::Core> >, std::equal_to<std::shared_ptr<folly::observer_detail::Core> >, std::allocator<std::shared_ptr<folly::observer_detail::Core> > >, folly::SharedMutexImpl<false, void, std::atomic, false, false> >, (folly::detail::MutexLevel)1>::withWLock<folly::observer_detail::Core::~Core()::$_2>(folly::ob server_detail::Core::~Core()::$_2&&) folly/Synchronized.h:210 > #5 0x7f6058343a17 in folly::observer_detail::Core::~Core() folly/experimental/observer/detail/Core.cpp:154 > #6 0x7f605838b8ca in std::_Sp_counted_ptr<folly::observer_detail::Core*, (__gnu_cxx::_Lock_policy)2>::_M_dispose() buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/bits/shared_ptr_base.h:378 > #7 0x7f605834d411 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/bits/shared_ptr_base.h:156 > #8 0x7f605834d332 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/bits/shared_ptr_base.h:686 > #9 0x7f605834d23a in std::__shared_ptr<folly::observer_detail::Core, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/bits/shared_ptr_base.h:1125 > #10 0x7f605833c416 in std::shared_ptr<folly::observer_detail::Core>::~shared_ptr() buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/bits/shared_ptr.h:93 > #11 0x7f6058376413 in folly::observer_detail::ObserverManager::scheduleRefresh(std::shared_ptr<folly::observer_detail::Core>, unsigned long)::'lambda'()::~() folly/experimental/observer/detail/ObserverManager.h:91 > #12 0x7f6058377014 in unsigned long folly::detail::function::execSmall<folly::observer_detail::ObserverManager::scheduleRefresh(std::shared_ptr<folly::observer_detail::Core>, unsigned long)::'lambda'()>(folly::detail::function::Op, folly::detail::function::Data*, folly::detail::function::Data*) folly/Function.h:592 > #13 0x7f6058377788 in folly::Function<void ()>::exec(folly::detail::function::Op, folly::detail::function::Data*, folly::detail::function::Data*) const folly/Function.h:649 > #14 0x7f6058376380 in folly::Function<void ()>::~Function() folly/Function.h:781 > #15 0x7f6058477b99 in folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()::operator()() const folly/experimental/observer/detail/ObserverManager.cpp:73 > #16 0x7f6058473de8 in void std::__invoke_impl<void, folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()>(std::__invoke_other, folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()&&) buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/bits/invoke.h:60 > #17 0x7f6058473c08 in std::__invoke_result<folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()>::type std::__invoke<folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()>(folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()&&) buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/bits/invok e.h:95 > #18 0x7f6058473b66 in decltype(std::__invoke(_S_declval<0ul>())) std::thread::_Invoker<std::tuple<folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/thread:234 > #19 0x7f6058473a43 in std::thread::_Invoker<std::tuple<folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()> >::operator()() buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/thread:243 > #20 0x7f6058473549 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<folly::observer_detail::ObserverManager::UpdatesManager::CurrentQueue::CurrentQueue()::'lambda'()> > >::_M_run() buck-out/cells/fbsource/gen/third-party/gcc/7.x/stdc++-headers#header-mode-symlink-tree-with-header-map,headers/thread:186 > #21 0x7f60576bac5f in std::execute_native_thread_routine(void*) third-party/gcc/7.x/libstdc++-v3/src/c++11/thread.cc:83 > #22 0x7f605639e6b5 in start_thread /home/engshare/third-party2/glibc/2.26/src/glibc-2.26/nptl/pthread_create.c:465:7 > #23 0x7f6055ecdebe in __GI___clone /home/engshare/third-party2/glibc/2.26/src/glibc-2.26/sysdeps/unix/sysv/linux/x86_64/clone.S:95 > > SUMMARY: UndefinedBehaviorSanitizer: unsigned-integer-overflow folly/experimental/observer/detail/Core.cpp:179:9 ``` Fix the error by rearranging increment and decrement operations. Reviewed By: leikahing Differential Revision: D19164999 fbshipit-source-id: d3c9b638492d0bf44c2acaac1e95fafe8b785182
facebook-github-bot
pushed a commit
that referenced
this pull request
Dec 19, 2019
Summary: Exposed by UBSAN's misaligned-pointer-use: ```lang=bash > folly/test/stl_tests/StlVectorTest.cpp:544:12: runtime error: upcast of misaligned address 0x0000feebdaed for type 'DataTracker<false>', which requires 8 byte alignment > 0x0000feebdaed: note: pointer points here > <memory cannot be printed> > #0 0x6c9b93 in DataTracker<false>::~DataTracker() folly/test/stl_tests/StlVectorTest.cpp:544 > #1 0x6c94fe in Data<0u, 0ul>::~Data() folly/test/stl_tests/StlVectorTest.cpp:605 > #2 0xcc5f93 in void test_iteratorInsertionN2<folly::fbvector<Data<0u, 0ul>, std::allocator<Data<0u, 0ul> > > >(std::integral_constant<bool, true>) folly/test/stl_tests/StlVectorTest.cpp:2422 > #3 0x5c9bac in void test_iteratorInsertionN3<folly::fbvector<Data<0u, 0ul>, std::allocator<Data<0u, 0ul> > > >() folly/test/stl_tests/StlVectorTest.cpp:2422 > #4 0x5c67bd in FBVector_iteratorInsertionN_Test::TestBody() folly/test/stl_tests/StlVectorTest.cpp:2422 > #5 0x7f9c4e5316c9 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) xplat/third-party/gmock/googletest-1.8.0/googletest/src/gtest.cc:2464 > #6 0x7f9c4e530dcc in testing::Test::Run() xplat/third-party/gmock/googletest-1.8.0/googletest/src/gtest.cc:2480 > #7 0x7f9c4e5350a0 in testing::TestInfo::Run() xplat/third-party/gmock/googletest-1.8.0/googletest/src/gtest.cc:2662 > #8 0x7f9c4e539408 in testing::TestCase::Run() xplat/third-party/gmock/googletest-1.8.0/googletest/src/gtest.cc:2780 > #9 0x7f9c4e55a672 in testing::internal::UnitTestImpl::RunAllTests() xplat/third-party/gmock/googletest-1.8.0/googletest/src/gtest.cc:4655 > #10 0x7f9c4e5595de in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) xplat/third-party/gmock/googletest-1.8.0/googletest/src/gtest.cc:2464 > #11 0x7f9c4e558b72 in testing::UnitTest::Run() xplat/third-party/gmock/googletest-1.8.0/googletest/src/gtest.cc:4263 > #12 0x6591f3 in RUN_ALL_TESTS() buck-out/cells/fbsource/gen/xplat/third-party/gmock/gtest_headers#header-mode-symlink-tree-with-header-map,headers/gtest/gtest.h:2247 > #13 0x659139 in main folly/test/stl_tests/StlVectorTest.cpp:3074 > #14 0x7f9c4c75b1a5 in __libc_start_main /home/engshare/third-party2/glibc/2.26/src/glibc-2.26/csu/libc-start.c:308:16 > #15 0x4de029 in _start /home/engshare/third-party2/glibc/2.26/src/glibc-2.26/sysdeps/x86_64/start.S:120 > > SUMMARY: UndefinedBehaviorSanitizer: misaligned-pointer-use folly/test/stl_tests/StlVectorTest.cpp:544:12 ``` Make the crafted pointer address aligned. Reviewed By: Gownta Differential Revision: D19166262 fbshipit-source-id: f766656d031079350838598b135275bdbc047642
facebook-github-bot
pushed a commit
that referenced
this pull request
Mar 8, 2023
Summary:
AsyncUDPSocket test cases are crashing when running under llvm15. During
debugging it seems that the issue is the fact that the code tries to allocated 0
size array. Changing the code to prevent such allocation.
This is not very clean why to fix, but I am not sure if there is better one.
Please let me know if you have any suggestions.
Sample crash:
```
$ buck test //folly/io/async/test:async_udp_socket_test
...
stdout:
Note: Google Test filter = AsyncUDPSocketTest.TestDetachAttach
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from AsyncUDPSocketTest
[ RUN ] AsyncUDPSocketTest.TestDetachAttach
stderr:
fbcode/folly/io/async/AsyncUDPSocket.cpp:699:10: runtime error: variable length array bound evaluates to non-positive value 0
#0 0x7f4d8ed93704 in folly::AsyncUDPSocket::writev(folly::SocketAddress const&, iovec const*, unsigned long, int) fbcode/folly/io/async/AsyncUDPSocket.cpp:698
#1 0x7f4d8ed9081f in folly::AsyncUDPSocket::writeGSO(folly::SocketAddress const&, std::unique_ptr<folly::IOBuf, std::default_delete<folly::IOBuf>> const&, int) fbcode/folly/io/async/AsyncUDPSocket.cpp:528
#2 0x7f4d8ed900b2 in folly::AsyncUDPSocket::write(folly::SocketAddress const&, std::unique_ptr<folly::IOBuf, std::default_delete<folly::IOBuf>> const&) fbcode/folly/io/async/AsyncUDPSocket.cpp:660
#3 0x350a05 in AsyncUDPSocketTest_TestDetachAttach_Test::TestBody() fbcode/folly/io/async/test/AsyncUDPSocketTest.cpp:914
#4 0x7f4d90dd1ad5 in testing::Test::Run() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:2682:50
#5 0x7f4d90dd1ad5 in testing::Test::Run() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:2672:6
#6 0x7f4d90dd1c64 in testing::TestInfo::Run() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:2861:14
#7 0x7f4d90dd1c64 in testing::TestInfo::Run() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:2833:6
#8 0x7f4d90dd2321 in testing::TestSuite::Run() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:3015:31
#9 0x7f4d90dd2321 in testing::TestSuite::Run() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:2993:6
#10 0x7f4d90dd2b1e in testing::internal::UnitTestImpl::RunAllTests() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:5855:47
#11 0x7f4d90dd1d87 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:2665:29
#12 0x7f4d90dd1d87 in testing::UnitTest::Run() /home/engshare/third-party2/googletest/1.11.0/src/googletest/googletest/src/gtest.cc:5438:55
#13 0x7f4d90d5c990 in RUN_ALL_TESTS() fbcode/third-party-buck/platform010/build/googletest/include/gtest/gtest.h:2490
#14 0x7f4d90d5c618 in main fbcode/common/gtest/LightMain.cpp:20
#15 0x7f4d8ea2c656 in __libc_start_call_main /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#16 0x7f4d8ea2c717 in __libc_start_main@GLIBC_2.2.5 /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../csu/libc-start.c:409:3
#17 0x33ea60 in _start /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../sysdeps/x86_64/start.S:116
...
```
Reviewed By: russoue, dmm-fb
Differential Revision: D43858875
fbshipit-source-id: 93749bab17027b6dfc0dbc01b6c183e501a5494c
facebook-github-bot
pushed a commit
that referenced
this pull request
Apr 27, 2024
Summary:
ThreadLocalDetailTest.MultiThreadedTest had a data race on std::vector because multiple threads were accessing and modifying the std::vector without a mutex. I update the code to use indexes such that the vector is not updated concurrently.
Previous run failure that this fixes:
```
stderr:
==================
WARNING: ThreadSanitizer: data race (pid=1249005)
Write of size 8 at 0x7fff195936d0 by main thread:
#0 std::vector<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>, std::allocator<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>>>::pop_back() fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/stl_vector.h:1228 (thread_local_detail_test+0x116c28)
#1 folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody() fbcode/folly/detail/test/ThreadLocalDetailTest.cpp:121 (thread_local_detail_test+0x101aba)
#2 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) fbsource/src/gtest.cc:2675 (libthird-party_googletest_1.14.0_gtest.so+0xacf3c)
#3 testing::Test::Run() fbsource/src/gtest.cc:2692 (libthird-party_googletest_1.14.0_gtest.so+0xacb9c)
#4 testing::TestInfo::Run() fbsource/src/gtest.cc:2841 (libthird-party_googletest_1.14.0_gtest.so+0xafa4a)
#5 testing::TestSuite::Run() fbsource/src/gtest.cc:3020 (libthird-party_googletest_1.14.0_gtest.so+0xb4303)
#6 testing::internal::UnitTestImpl::RunAllTests() fbsource/src/gtest.cc:5925 (libthird-party_googletest_1.14.0_gtest.so+0xd105e)
#7 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) fbsource/src/gtest.cc:2675 (libthird-party_googletest_1.14.0_gtest.so+0xd08f1)
#8 testing::UnitTest::Run() fbsource/src/gtest.cc:5489 (libthird-party_googletest_1.14.0_gtest.so+0xd037e)
#9 RUN_ALL_TESTS() fbsource/gtest/gtest.h:2317 (libcommon_gtest_light_main.so+0x22a7)
#10 main fbcode/common/gtest/LightMain.cpp:20 (libcommon_gtest_light_main.so+0x2131)
Previous read of size 8 at 0x7fff195936d0 by thread T123:
#0 std::vector<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>, std::allocator<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>>>::size() const fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/stl_vector.h:919 (thread_local_detail_test+0x11b0bd)
#1 std::vector<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>, std::allocator<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>>>::operator[](unsigned long) fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/stl_vector.h:1045 (thread_local_detail_test+0x11d101)
#2 folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0::operator()() const fbcode/folly/detail/test/ThreadLocalDetailTest.cpp:97 (thread_local_detail_test+0x11d08c)
#3 void std::__invoke_impl<void, folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0>(std::__invoke_other, folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0&&) fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/invoke.h:61 (thread_local_detail_test+0x11cf95)
#4 std::__invoke_result<folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0>::type std::__invoke<folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0>(folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0&&) fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/invoke.h:96 (thread_local_detail_test+0x11cf05)
#5 void std::thread::_Invoker<std::tuple<folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0>>::_M_invoke<0ul>(std::_Index_tuple<0ul>) fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/std_thread.h:253 (thread_local_detail_test+0x11cebd)
#6 std::thread::_Invoker<std::tuple<folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0>>::operator()() fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/std_thread.h:260 (thread_local_detail_test+0x11ce65)
#7 std::thread::_State_impl<std::thread::_Invoker<std::tuple<folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody()::$_0>>>::_M_run() fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/std_thread.h:211 (thread_local_detail_test+0x11cd79)
#8 execute_native_thread_routine /home/engshare/third-party2/libgcc/11.x/src/gcc-11.x/x86_64-facebook-linux/libstdc++-v3/src/c++11/../../../.././libstdc++-v3/src/c++11/thread.cc:82:18 (libstdc++.so.6+0xdf4e4) (BuildId: 452d1cdae868baeeb2fdf1ab140f1c219bf50c6e)
Location is stack of main thread.
Location is global '??' at 0x7fff19575000 ([stack]+0x1e6d0)
Thread T123 (tid=1249233, running) created by main thread at:
#0 pthread_create <null> (thread_local_detail_test+0x156bef)
#1 __gthread_create /home/engshare/third-party2/libgcc/11.x/src/gcc-11.x/x86_64-facebook-linux/libstdc++-v3/include/x86_64-facebook-linux/bits/gthr-default.h:663:35 (libstdc++.so.6+0xdf80e) (BuildId: 452d1cdae868baeeb2fdf1ab140f1c219bf50c6e)
#2 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State>>, void (*)()) /home/engshare/third-party2/libgcc/11.x/src/gcc-11.x/x86_64-facebook-linux/libstdc++-v3/src/c++11/../../../.././libstdc++-v3/src/c++11/thread.cc:147:37 (libstdc++.so.6+0xdf80e)
#3 folly::threadlocal_detail::ThreadLocalDetailTest_MultiThreadedTest_Test::TestBody() fbcode/folly/detail/test/ThreadLocalDetailTest.cpp:93 (thread_local_detail_test+0x1015cd)
#4 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) fbsource/src/gtest.cc:2675 (libthird-party_googletest_1.14.0_gtest.so+0xacf3c)
#5 testing::Test::Run() fbsource/src/gtest.cc:2692 (libthird-party_googletest_1.14.0_gtest.so+0xacb9c)
#6 testing::TestInfo::Run() fbsource/src/gtest.cc:2841 (libthird-party_googletest_1.14.0_gtest.so+0xafa4a)
#7 testing::TestSuite::Run() fbsource/src/gtest.cc:3020 (libthird-party_googletest_1.14.0_gtest.so+0xb4303)
#8 testing::internal::UnitTestImpl::RunAllTests() fbsource/src/gtest.cc:5925 (libthird-party_googletest_1.14.0_gtest.so+0xd105e)
#9 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) fbsource/src/gtest.cc:2675 (libthird-party_googletest_1.14.0_gtest.so+0xd08f1)
#10 testing::UnitTest::Run() fbsource/src/gtest.cc:5489 (libthird-party_googletest_1.14.0_gtest.so+0xd037e)
#11 RUN_ALL_TESTS() fbsource/gtest/gtest.h:2317 (libcommon_gtest_light_main.so+0x22a7)
#12 main fbcode/common/gtest/LightMain.cpp:20 (libcommon_gtest_light_main.so+0x2131)
ThreadSanitizer: data race fbcode/third-party-buck/platform010/build/libgcc/include/c++/trunk/bits/stl_vector.h:1228 in std::vector<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>, std::allocator<std::unique_ptr<folly::test::Barrier, std::default_delete<folly::test::Barrier>>>>::pop_back()
==================
ThreadSanitizer: reported 1 warnings
```
Reviewed By: yfeldblum
Differential Revision: D56643303
fbshipit-source-id: cc364817ae79bc6418cc07faa35e1bcd21830c66
facebook-github-bot
pushed a commit
that referenced
this pull request
Aug 12, 2024
Summary: Ucache with io_uring is crashing with this stack trace: ``` (lldb) bt * thread #1, name = 'ucache', stop reason = signal SIGSEGV: address not mapped to object * frame #0: 0x0000000000000000 frame #1: 0x00007f517ba44560 libc.so.6`__restore_rt at libc_sigaction.c:13 frame #2: 0x000000000a16e249 ucache`folly::AsyncIoUringSocket::ReadSqe::callback(this=0x00007f498c5955e0, cqe=<unavailable>) at AsyncIoUringSocket.cpp:639 frame #3: 0x000000000964196a ucache`folly::IoUringBackend::getActiveEvents(folly::IoUringBackend::WaitForEventsMode) [inlined] folly::IoSqeBase::internalCallback(this=<unavailable>, cqe=<unavailable>) at IoUringBackend.cpp:0 frame #4: 0x000000000964195c ucache`folly::IoUringBackend::getActiveEvents(folly::IoUringBackend::WaitForEventsMode) [inlined] folly::IoUringBackend::internalProcessCqe(this=0x00007f4a8f989c00, maxGet=4294967295, mode=NORMAL) at IoUringBackend.cpp:1556 frame #5: 0x000000000964190f ucache`folly::IoUringBackend::getActiveEvents(this=0x00007f4a8f989c00, waitForEvents=<unavailable>) at IoUringBackend.cpp:1527 frame #6: 0x0000000009640ac9 ucache`folly::IoUringBackend::eb_event_base_loop(this=0x00007f4a8f989c00, flags=1) at IoUringBackend.cpp:1178 frame #7: 0x000000001b61547c ucache`folly::EventBase::loopMain(this=0x00007f4a8f97af00, flags=0, options=<unavailable>) at EventBase.cpp:0 frame #8: 0x000000001bab9a2d ucache`folly::EventBase::loopBody(this=0x00007f4a8f97af00, flags=0, options=(ignoreKeepAlive = false, allowSuspension = false)) at EventBase.cpp:513 frame #9: 0x000000000a3a6c90 ucache`folly::EventBase::loop(this=<unavailable>) at EventBase.cpp:474 frame #10: 0x000000000a3a75f7 ucache`folly::EventBase::loopForever(this=<unavailable>) at EventBase.cpp:781 frame #11: 0x000000000a436907 ucache`folly::IOThreadPoolExecutor::threadRun(this=0x00007f4da3fce1c0, thread=<unavailable>) at IOThreadPoolExecutor.cpp:240 frame #12: 0x0000000009ed68b8 ucache`void std::__invoke_impl<void, void (folly::ThreadPoolExecutor::*&)(std::shared_ptr<folly::ThreadPoolExecutor::Thread>), folly::ThreadPoolExecutor*&, std::shared_ptr<folly::ThreadPoolExecutor::Thread>&>((null)=<unavailable>, __f=<unavailable>, __t=<unavailable>, __args=<unavailable>) at invoke.h:74 frame #13: 0x00007f517b6df4e5 libstdc++.so.6`std::execute_native_thread_routine(__p=0x00007f4da01bdbe0) at thread.cc:82:18 frame #14: 0x00007f517ba9abc9 libc.so.6`start_thread(arg=<unavailable>) at pthread_create.c:434:8 frame #15: 0x00007f517bb2cf5c libc.so.6`__clone3 at clone3.S:81 ``` In frame 2 the offending function is `ReadSqe::callback()`: https://fburl.com/code/4fb46hdq The problem is that `readCallback_` is null: ``` (lldb) fr v readCallback_ (folly::AsyncReader::ReadCallback *) readCallback_ = nullptr ``` However, `readCallback_` is checked earlier in the the function `ReadSqe::callback()`: https://fburl.com/code/dhnndk29 `AsyncIoUringSocket::readError()` now fails all pending writes and calls `writeErr()`, whose implementation can then close out a socket and call `AsyncIoUringSocket::setReadCB(nullptr)` to change the callback. Move the call to `AsyncIoUringSocket::readError()` after the call to `readCallback_`. Reviewed By: dmm-fb Differential Revision: D60880377 fbshipit-source-id: 42d2f430cd3dc3f4787d0e4c29da7c8ef31ba9a8
facebook-github-bot
pushed a commit
that referenced
this pull request
Apr 25, 2025
…hRttiImpl
Summary:
### Overview
I observed failures like:
```
==33555==ERROR: AddressSanitizer: unknown-crash on address 0x800000010516ecee at pc 0x0001062597f4 bp 0x00016b80d470 sp 0x00016b80cc08
READ of size 155 at 0x800000010516ecee thread T0
#0 0x0001062597f0 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x157f0)
#1 0x000104f58508 in std::type_info::before[abi:ne180100](std::type_info const&) const+0x8c (core_tests_binary:arm64+0x10096c508)
#2 0x000104f58418 in std::__1::type_index::operator<[abi:ne180100](std::__1::type_index const&) const+0xa4 (core_tests_binary:arm64+0x10096c418)
#3 0x000104f57c00 in void* folly::detail::(anonymous namespace)::StaticSingletonManagerWithRttiImpl::create<folly::detail::StaticSingletonManagerWithRtti::Arg>(folly::detail::StaticSingletonManagerWithRtti::Arg&)+0x148 (core_tests_binary:arm64+0x10096bc00)
#4 0x000104f58110 in void* folly::detail::StaticSingletonManagerWithRtti::create_<true>(folly::detail::StaticSingletonManagerWithRtti::Arg&)+0xc (core_tests_binary:arm64+0x10096c110)
#5 0x000104fc0b64 in folly::detail::UniqueInstance::enforce(folly::detail::UniqueInstance::Arg&)+0x30c (core_tests_binary:arm64+0x1009d4b64)
#6 0x000104793064 in __cxx_global_var_init.286+0x34 (core_tests_binary:arm64+0x1001a7064)
#7 0x00018fc4ac14 (<unknown module>)
#8 0x00018fc87014 (<unknown module>)
#9 0x00018fca6ccc (<unknown module>)
#10 0x00018fca3abc (<unknown module>)
#11 0x00018fca51fc (<unknown module>)
#12 0x00018fc86ae4 (<unknown module>)
#13 0x00018fc4a9cc (<unknown module>)
#14 0x00018fc52358 (<unknown module>)
#15 0x00018fc4b168 (<unknown module>)
#16 0x00018fc4f8d8 (<unknown module>)
#17 0x00018fc4b474 (<unknown module>)
#18 0x00018fc6c284 (<unknown module>)
#19 0x00018fc2fda8 (<unknown module>)
#20 0x00018fc2f180 (<unknown module>)
#21 0x00018fc2eafc (<unknown module>)
Address 0x800000010516ecee is a wild pointer inside of access range of size 0x00000000009b.
AddressSanitizer: unknown-crash (core_tests_binary:arm64+0x10096c508) in std::type_info::before[abi:ne180100](std::type_info const&) const+0x8c
==33555==ABORTING
```
Looks like the address sanitizer found a memory issue in the implementation of `std::type_info::before`, when I force it to use the more robust type_info comparison algorithm. I couldn't find any references to known problems around this, internally or externally, and unfortunately that's code we can't easily fix.
Instead of relying on the seemingly problematic implementation of `std::type_info::before`, I'm changing the `std::map` to an `std::unordered_map` which instead relies on equality comparison, which is in turn directly controlled by `_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION`. See discussion in the comments for additional context on this decision.
Reviewed By: yfeldblum
Differential Revision: D73379250
fbshipit-source-id: 257bb77a8b6bb69b364bf4c6edcbdb160c84ca74
meta-codesync bot
pushed a commit
that referenced
this pull request
Dec 1, 2025
Summary: ## TL;DR The `setgid()` libc implementation should not be used after vfork, as there is a potential for deadlock due to shared address space. ## Context Folly::Subprocess uses vfork() instead of fork(), mainly for efficiency reasons. As an interaction of `vfork()`, the child process shares the address space with the parent process. Folly::Subprocess currently uses the setgid() glibc function. **For only linux**, gilbc manually iterates through all threads, and sets the gid for each thread, in https://fburl.com/ler48t68. Therefore, setgid() holds a lock while iterating through each thread. Note that this lock is shared with the parent, because the child and parent share the same memory space. Therefore, there is a possible interaction, where if the parent process acquires the lock and is killed for any reason (SIGTERM, crash, etc), the child process is blocked indefinitely Example stack trace: ``` [root@twshared1674.03.hil1 ~]# quickstack -p 4111332 2025-11-22 12:30:42 761077: Setting mount namespace failed. Errno: 22 2025-11-22 12:30:42 761120: Target pid: 4111332 (inside container: 4111332) 2025-11-22 12:30:42 761528: Reading process symbols.. 2025-11-22 12:30:42 869656: Gathering stack traces.. 2025-11-22 12:30:42 869817: Printing stack traces.. 2025-11-22 12:30:42 869836: Total Traced Time: 0.126 milliseconds 2025-11-22 12:30:42 869844: Average Traced Time Per LWP: 0.126 milliseconds 2025-11-22 12:30:42 869850: Longest Traced LWP: LWP 4111332, 0.126 milliseconds Thread 1 (LWP 4111332): #1 0x00007f03a8297377 in __GI___lll_lock_wait_private () from /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/nptl/lowlevellock.c:35 #2 0x00007f03a82f298e in __setgid () from /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/posix/../sysdeps/unix/sysv/linux/setgid.c:31 #3 0x000000000a523c6f in folly::Subprocess::prepareChild () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #4 0x0000000004152801 in folly::Subprocess::spawnInternalDoFork () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #5 0x0000000004153578 in folly::Subprocess::spawn () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #6 0x0000000004152270 in folly::Subprocess::Subprocess () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #7 0x00000000041568bc in facebook::fbagent::FollyRunner::run () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #8 0x0000000003d542b2 in facebook::fbagent::DefaultTask::run () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #9 0x0000000004095836 in apache::thrift::concurrency::ThreadManager::Impl::Worker::run () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #10 0x000000000ae7e570 in apache::thrift::concurrency::(anonymous namespace)::InitRunnable::run () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #11 0x000000000ae7f312 in apache::thrift::concurrency::PthreadThread::threadMain () from /usr/local/fbprojects/fbagent/bin/cppfbagentd #12 0x00007f03a829abc9 in start_thread () from /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/nptl/pthread_create.c:434 2025-11-22 12:30:42 882619: Done. ``` ## Fix Call the setgid syscall directly, rather than using glibc. Reviewed By: yfeldblum Differential Revision: D87717072 fbshipit-source-id: d3c13f6b70912f02192870d94dbca8fe14493373
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.