[Lldb-commits] [lldb] 1b1d981 - Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

[Pavel Labath via lldb-commits]

On 30/09/2020 23:21, Jim Ingham wrote:
> The test doesn’t seem to be flakey in the “run it a bunch of times and
> it will eventually fail” type flakey.  I ran the test 200 times on my
> machine and didn’t get a failure.

Actually, it seems like exactly the typical kind of flaky test to me --
it mostly works when run on its own, but starts failing as soon as the
system comes under load.

It didn't fail for me either for over 100 iterations. However, as soon
as I cranked up the cpu load (compiling llvm is good at that), it failed
almost immediately.

It also doesn't seem to be related to the way the stop hook resumes the
process.
<http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9516/steps/test/logs/stdio>
is one example where the auto_continue version of the test fails, and I
have seen both tests fail on my machine.

I have some traces of failing and successful runs of the test (will send
them to you in a private email). I didn't dive too deeply, but the
problem does not seem to be related to python stop hooks. It looks more
like a general stop hook bug, which we've had problems with in the past.

The problems seems to be that the process.Continue() on the main thread
returns early, and so the subsequent checks (for the topmost frame etc.)
execute concurrently with the "step out" action. In the "Failure" file
I'll send you you can see that (line 9222) SBFrame::GetFunctionName is
called before the inferior process stops in the main function (the
processing of that happens immediately after that line, on the
"intern-state" thread).

pl