Long timeouts for the MacOSX SystemRuntime plugins under ASAN; else quick.
authorJason Molenda <jmolenda@apple.com>
Sat, 7 Sep 2019 01:38:37 +0000 (01:38 +0000)
committerJason Molenda <jmolenda@apple.com>
Sat, 7 Sep 2019 01:38:37 +0000 (01:38 +0000)
commit5b0a687d891e661432dc2a12637a9a956ad68f78
tree87de80dfaa67604e8e2407e8cb4bdc26bcfa7ed4
parent0aee3873214682b0db7e9a876a8baedbb22a1039
Long timeouts for the MacOSX SystemRuntime plugins under ASAN; else quick.

In April via r357829, Adrian unified timeouts across lldb and set the
default value high so that we wouldn't get timeouts on ASAN bots that
were running under load.

The library that the MacOSX SystemRuntime has functions that need
to take a lock, and if that lock is held already, those functions
will never complete; we're seeing the 15 second timeout being hit
with inferiors that are doing a lot of enqueuing and dequeuing of
libdispatch work items causing this deadlocking behavior.

This patch reverts to a very short timeout for these SystemRuntime
function calls, given the behavior of this library that they are
calling into.  When lldb is built with AddressSanitizer enabled,
they will use the default 15 second timeout.

tl;dr: this reverts to the previous timeouts for these SystemRuntime
inf func calls.

<rdar://problem/54538149>

llvm-svn: 371280
lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp