- Added two common completions: ProcessIDs and ProcessNames, which are refactored from their original dedicated option completions;
- Removed the dedicated option completion functions of process attach and platform process attach, so that they can use arg-type-bound common completions instead;
- Bound eArgTypePid to the pid completion, eArgTypeProcessName to the process name completion in CommandObject.cpp;
- Added a related test case.
Details
Diff Detail
Event Timeline
lldb/test/API/functionalities/completion/TestCompletion.py | ||
---|---|---|
127 | Why is this necessary? | |
131 | If self.complete_from_to fails and raises and exception, the process potentially won't terminate. Can you wrap this in a try-except-finally? You should be able to just re-raise the exception in the except clause. |
- For the necessity it's because lldb does filter out its own pid and the pid of the process it already attached to, so I create a process here to provide an available pid which is known to us and able to be found by the completion implementation.
- For the child process termination problem, with the process flag value daemon set to True, this child process should be terminated automatically if this test process is killed due to any exception.
If I did misunderstand your meaning or my solution is not considerate, please be in more detail, thx!
So just to give some additional explanation for the Process thing: LLDB doesn't provide the pid for itself when listing process to attach to (which would just break LLDB if the user actually attaches) and there isn't really any other pid we know to exist on the target system (we could speculate 1 is always running, but that seems a bit sketchy). And a program which we already stopped is apparently also not in the list (we can't double attach). So this test has to launch some process that we know is waiting for us and that hasn't an attached LLDB. @MrHate I think this should be documented in the test.
Beside that this seems alright to me beside some minor nits.
lldb/source/Commands/CommandCompletions.cpp | ||
---|---|---|
656 | You can do a C++11 for loop over the process_infos (it's just a std::vector). | |
lldb/test/API/functionalities/completion/TestCompletion.py | ||
125 | Could this just be some kind of sleep or something else that doesn't actively use CPU? |
- modified for loop;
- replaced pass with time.sleep(1) so that the test process won't take up CPU.
LGTM, but I have some minor things. I would do them for you when merging but I just want to make sure you see them so I'll send this review back to you :)
lldb/test/API/functionalities/completion/TestCompletion.py | ||
---|---|---|
122 | This test probably won't work in remote test suite runs (which is essentially when LLDB's test suit is run but all the target programs are on another machine. Usually that's used for testing debugging on a phone). Mainly because the process we create here will be created on the system where the test runs and not the remote machine. But I also don't think there is a nice way to create a dummy process that we can attach to on a remote machine, so I think this is fine. But you should add a @skipIfRemote to the test that we don't see the test failures when someone runs the tests on a remote machine. So like this: @skipIfRemote def test_process_attach_dash_p(self): (You probably already saw the @skipIf... markers in LLDB tests. Those are just used to disable the test on certain configurations where they are not supposed to pass). | |
127 | Can you add a comment that this is done because we need to have a process that we can always attach to (and that LLDB itself and an already attached process is out of question because we can't attach to those). |
- added @skipIfRemote to the test case;
- added the comment explaining the process creation.
- Set daemon to True on creating process, so that it will be killed with the test case ending (which was set to False by mistake).
LGTM now
lldb/test/API/functionalities/completion/TestCompletion.py | ||
---|---|---|
131 | Why daemon=True should probably be documented. I can do that when merging. |
- Rebased the patch with the latest master branch from Github;
- In test, uses the pid got from psutil.pids()[0] instead of the one generated by creating a new process in case the pickle error.
You can do a C++11 for loop over the process_infos (it's just a std::vector).