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

1 files changed, 4 insertions, 0 deletions

diff --git a/lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp b/lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
index fd4d21d8071..3dcfda28397 100644
--- a/lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
+++ b/lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
@@ -341,7 +341,11 @@ AppleGetThreadItemInfoHandler::GetThreadItemInfo(Thread &thread,
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   options.SetStopOthers(true);
+#if __has_feature(address_sanitizer)
   options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
+#else
+  options.SetTimeout(std::chrono::milliseconds(500));
+#endif
   options.SetTryAllThreads(false);
   options.SetIsForUtilityExpr(true);
   thread.CalculateExecutionContext(exe_ctx);