Page MenuHomePhabricator

[platform process list] add a flag for showing the processes of all users
ClosedPublic

Authored by wallace on Oct 2 2019, 1:06 PM.

Details

Summary

For context: https://reviews.llvm.org/D68293

We need a way to show all the processes on android regardless of the user id.
When you run platform process list, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.

Before:

PID    PARENT USER       TRIPLE                   NAME
====== ====== ========== ======================== ============================
3234   1                 aarch64-unknown-linux-android adbd
8034   3234              aarch64-unknown-linux-android sh
9096   3234              aarch64-unknown-linux-android sh
9098   9096              aarch64-unknown-linux-android lldb-server
(lldb) ^D

Now:

(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID    PARENT USER       TRIPLE                   NAME
====== ====== ========== ======================== ============================
1      0                                          init
524    1                                          init
525    1                                          init
531    1                                          ueventd
568    1                                          logd
569    1                 aarch64-unknown-linux-android servicemanager
570    1                 aarch64-unknown-linux-android hwservicemanager
571    1                 aarch64-unknown-linux-android vndservicemanager
577    1                 aarch64-unknown-linux-android qseecomd
580    577               aarch64-unknown-linux-android qseecomd
...
23816  979                                        com.android.providers.calendar
24600  979                                        com.verizon.mips.services
27888  979                                        com.hualai
28043  2378                                       com.android.chrome:sandboxed_process0
31449  979                                        com.att.shm
31779  979                                        com.samsung.android.authfw
31846  979                                        com.samsung.android.server.iris
32014  979                                        com.samsung.android.MtpApplication
32045  979                                        com.samsung.InputEventApp

Event Timeline

wallace created this revision.Oct 2 2019, 1:06 PM

Btw, I couldn't find a better short command than 'x', but if you have a better suggestion, i'd be happy to accept it :)

labath added a comment.Oct 3 2019, 4:38 AM

I think the fact that all of our options *must* have a short version is a pretty serious deficiency in our option parsing system. It results in a lot of unintuitive options that nobody uses because they can't guess what they stand for. But anyway, -x seems as good as any, as all the good alternatives are already taken.

For testing this, I think the best option would be something similar to the gdb-client suite (test/testcases/functionalities/gdb_remote_client), which allows you to mock the remote end of a connection. It is currently geared toward talking to the gdb server (and not the platform), but as the underlying protocol is the same, I am hoping that it can be repurposed to this use case fairly easily. I am imagining a flow where you create a mock server, configure it to respond appropriately to any packet that lldb issues, and then run e.g. "platform select remote-linux", "platform connect connect://localhost:%d", "platform proces list --all-users".

Setting that up is a bit overkill for a simple patch as this one, but as it looks like you're going to be doing a lot of work in this area in the near future, I think it makes sense to set up some testing infrastructure early.

wallace updated this revision to Diff 223358.Oct 4 2019, 6:56 PM

added a basic python test

It was a nice learning experience and fortunately there was no need to add any intrusive code

labath accepted this revision.Oct 7 2019, 2:04 AM

LG, thanks for the test.

lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py
31

Maybe also check that some of the values from the mock response made it through? (e.g., pid, process name)

This revision is now accepted and ready to land.Oct 7 2019, 2:04 AM
wallace marked an inline comment as done.Oct 7 2019, 10:46 AM
wallace added inline comments.
lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py
31

I'm adding that in the other diffs, but i'll make stricter checks anyway

shafik added a subscriber: shafik.Oct 7 2019, 2:33 PM

@wallace it looks like TestPlatformClient.py is failing on osx see green dragon log here: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/2317/testReport/junit/lldb-Suite/functionalities_gdb_remote_client/TestPlatformClient_py/

======================================================================
FAIL: test_process_list_with_all_users (TestPlatformClient.TestPlatformClient)
   Test connecting to a remote linux platform
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py", line 30, in test_process_list_with_all_users
    startstr="1 matching process was found", endstr="process" + os.linesep)
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2309, in expect
    inHistory=inHistory)
AssertionError: False is not True : Command 'platform process list -x
Error output:
error: no processes were found on the "remote-linux" platform
' returns successfully

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py", line 34, in test_process_list_with_all_users
    self.runCmd("platform disconnect")
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2068, in runCmd
    msg if (msg) else CMD_MSG(cmd))
AssertionError: False is not True : Command 'platform disconnect
Error output:
error: not connected to 'remote-linux'
' returns successfully
Config=x86_64-/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-10
----------------------------------------------------------------------
Ran 1 test in 0.043s

RESULT: FAILED (0 passes, 1 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes)

damn, i'll rebase and try to fix it

The windows LLDB bot also has the same failure: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9600

Please make sure your fix works for both.

shafik added a comment.Oct 8 2019, 9:24 AM

I reverted this change b/c the green dragon bots have been red for too long.

When you fix the problem please make sure you add

Differential Revision: https://reviews.llvm.org/D68354

to your commit message.

wallace closed this revision.Oct 8 2019, 1:03 PM

this was reverted

wallace reopened this revision.Oct 11 2019, 12:33 PM
This revision is now accepted and ready to land.Oct 11 2019, 12:33 PM
wallace updated this revision to Diff 224656.Oct 11 2019, 12:34 PM

now it should work, the test pass

wallace updated this revision to Diff 224716.Oct 11 2019, 5:41 PM

another try

wallace updated this revision to Diff 224717.Oct 11 2019, 6:30 PM

adding some logging for exceptions in the mock server

wallace updated this revision to Diff 224721.Oct 11 2019, 7:05 PM

after the logging finally found the bug, it's was an encoding issue due to a different python version

wallace updated this revision to Diff 224722.Oct 11 2019, 7:33 PM

i think i finally wrote something that works python 2 and 3

wallace closed this revision.Mon, Oct 14, 4:31 PM