[Lldb-commits] [lldb] r354149 - Disable stop-hook-threads.test on Linux

[Jorge Gorbe Moya via lldb-commits]

Author: jgorbe
Date: Fri Feb 15 09:54:00 2019
New Revision: 354149

URL: http://llvm.org/viewvc/llvm-project?rev=354149&view=rev
Log:
Disable stop-hook-threads.test on Linux

ExecControl/StopHook/stop-hook-threads.test is flaky on Linux (it's
consistently failing on my machine, but doesn't fail on a co-worker's).
I'm seeing the following assertion failure:

```
CommandObject.cpp:145: bool lldb_private::CommandObject::CheckRequirements(lldb_private::CommandReturnObject&): Assertion `m_exe_ctx.GetTargetPtr() == NULL' failed.
```

Interestingly, this doesn't happen when typing the same commands in
interactive mode. The cause seems to be that, in synchronous execution
mode continue waits until the process stops again, and that includes
running any stop-hooks for that later stop, so we end with a stack trace
like this (lots of frames omitted for clarity):

```
abort()
CommandObject::CheckRequirements() <-- this is again the same instance of CommandObjectProcessContinue, fails assertion because the previous continue command hasn't finished.
Target::RunStopHooks()
CommandObjectProcessContinue::DoExecute()
Target::RunStopHooks()
```

In general, it seems like using process control commands inside
stop-hooks does not have very well defined semantics. You don't even
need multiple threads to make that assertion fail, you can build

```
int main() {
  printf("1\n");  // break1
  printf("2\n");  // break2
}
```

and then on lldb

```
target stop-hook add -o continue
break set -f stop-hook-simple.cpp -p "break1"
break set -f stop-hook-simple.cpp -p "break2"
run
```

In this case it's even worse because the presence of multiple threads
makes it prone to race conditions. In some tests I ran with a simpler
version of this test case, I was hitting either the previous assertion
failure or the following issue:

1. Two threads reach a breakpoint
2. First stop-hook does a process continue
3. Threads end
4. Second stop-hook runs, complains about process not existing.

This change disables the test on Linux. It's already marked as XFAIL on
Windows, so maybe we should just delete it until it's clear what should
be the expected behavior in these cases. Or maybe try to come up with a
way to write a similar multithreaded test without calling continue from
a stop hook, I don't know.

Differential Revision: https://reviews.llvm.org/D58257

Modified:
    lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test

Modified: lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test?rev=354149&r1=354148&r2=354149&view=diff
==============================================================================
--- lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test (original)
+++ lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test Fri Feb 15 09:54:00 2019
@@ -4,6 +4,7 @@
 # RUN: %lldb -b -s %p/Inputs/stop-hook-threads-2.lldbinit -s %s -f %t \
 # RUN:     | FileCheck --check-prefix=CHECK --check-prefix=CHECK-FILTER %s
 # XFAIL: system-windows
+# UNSUPPORTED: linux
 
 thread list
 break set -f stop-hook-threads.cpp -p "Set break point at this line"