I was debugging a remote test failure in TestSendSignals.py when run on a remote platform, and I can’t understand how this test ever passed in that case.
The test sets a breakpoint, launches a process (with SBTarget.Launch) and then once we stop at the breakpoint, it switches the debugger to Async mode, and issues Continue. Then, if there’s a remote platform, it expects an eStateConnected event.
But all the events up to the stop for the breakpoint have already been consumed (otherwise we wouldn’t be publicly stopped at the breakpoint). So where is that eStateConnected event supposed to come from? This check only happens for remote platforms, so it won’t matter for most test suite runs. I can’t get it to succeed on the remote platforms I have access to.
I can just remove the check, but really, if it is passing somewhere, IMO that would be a bug and I’d like to know how to fix it…
I don’t know the internals well enough to say if it should be expected but I can say that Linaro doesn’t run the test suite this way. I do for development with qemu-system so I tried it there and got:
FAIL: test_with_run_command_dwarf (TestSendSignal.SendSignalTestCase)
Test that lldb command 'process signal SIGUSR1' sends a signal to the inferior process.
Traceback (most recent call last):
File "/work/open_source/lldb-cross-compile/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1673, in test_method
File "/work/open_source/lldb-cross-compile/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 127, in wrapper
File "/work/open_source/lldb-cross-compile/llvm-project/lldb/test/API/functionalities/signal/TestSendSignal.py", line 75, in test_with_run_command
File "/work/open_source/lldb-cross-compile/llvm-project/lldb/test/API/functionalities/signal/TestSendSignal.py", line 111, in match_state
AssertionError: 6 != 2 : It was the connected state.
Same thing you got I expect. If I remove that check the tests pass.
Would we expect remote platforms to behave differently here? I guess the switch to async could be a reconnect of a sort.
That line was introduced in 2015 (⚙ D8714 Fix TestSendSignal.py for remote.), which was when we were bringing up remote linux support. Given that is all that patch does, I am assuming this is how things worked at some point. However, that was quite some time ago, and there was a lot of changes in how we handle events and launches since then. Given that we are not running the remote test suite regularly, I’d assume that somewhere along the line this got fixed, but the test was not updated.
Cool, thanks. I’ll just remove that check, the behavior it was asserting was definitely not correct. The check for the running event immediately afterwards will keep the incorrect behavior from creeping back in, so that should be all that’s needed.