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

[Raphael “Teemperor” Isemann via lldb-commits]

+1, I have two machines with very similar setup where only the one that is under heavy load sees the test failures.

- Raphael

> On 1 Oct 2020, at 14:24, Pavel Labath <pavel at labath.sk> wrote:
> 
> 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