+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 <pa...@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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
