jgorbe created this revision.
jgorbe added reviewers: labath, zturner.
Herald added a subscriber: jdoerfert.
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
#include <cstdio>
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.
https://reviews.llvm.org/D58257
Files:
lldb/lit/ExecControl/StopHook/stop-hook-threads.test
Index: lldb/lit/ExecControl/StopHook/stop-hook-threads.test
===================================================================
--- lldb/lit/ExecControl/StopHook/stop-hook-threads.test
+++ lldb/lit/ExecControl/StopHook/stop-hook-threads.test
@@ -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"
Index: lldb/lit/ExecControl/StopHook/stop-hook-threads.test
===================================================================
--- lldb/lit/ExecControl/StopHook/stop-hook-threads.test
+++ lldb/lit/ExecControl/StopHook/stop-hook-threads.test
@@ -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"
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
