[Toybox] ps down, top to go

[Rob Landley]

On 05/09/2016 07:46 PM, enh wrote:
> On Mon, May 9, 2016 at 5:28 PM, enh <enh at google.com> wrote:
>> On Mon, May 9, 2016 at 4:47 PM, Rob Landley <rob at landley.net> wrote:
>>>
>>>
>>> On 05/06/2016 11:49 PM, enh wrote:
>>>> On Fri, May 6, 2016 at 9:11 PM, Rob Landley <rob at landley.net> wrote:
>>>>> On 05/06/2016 08:34 PM, enh wrote:
>>>>>> On Fri, May 6, 2016 at 6:01 PM, Rob Landley <rob at landley.net> wrote:
>>>>>>>>  1794  1806 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_1
>>>>>>>>  com.android.onetimeinitializer
>>>>>>>>  1794  1807 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_2
>>>>>>>>  com.android.onetimeinitializer
>>>>>>>>  1811  1811 u0_a24   20   0   0% S 1518092K  57752K  bg
>>>>>>>> ndroid.calendar com.android.calendar
>>>>>>>>  1811  1816 u0_a24   29   9   0% S 1518092K  57752K  bg Jit thread
>>>>>>>> pool com.android.calendar
>>>>>>>
>>>>>>> Wordwrapping in the original?
>>>>>>
>>>>>> yeah, sorry. gmail hates long lines.
>>>>>
>>>>> Makes it hard to see what you're going for, but I _think_ I understand.
>>>>> Your fields are padded to fixed starting points and "thread name" is
>>>>> whitespaced out if this isn't a thread?
>>>>
>>>> well, i can use field:123 to deal with that, plus thread names are
>>>> limited to 12 characters or so by the kernel anyway...
>>>>
>>>> my real problem is that i don't currently have a field that gives me
>>>> the process name in -T/-H mode.
>>>
>>> Define "process name"?
>>>
>>> There are 6 right now: args, cmd, cmdline, comm, command, and name.
>>>
>>> COMM is stat[2], NAME is argv[0] minus the path, COMMAND is argv[0] with
>>> the path.
>>>
>>> Those are the three variants of "process name", the rest show command
>>> line arguments too: CMDLINE is the full unmodified command line. ARGS is
>>> the full command line using NAME for argv[0] (I.E. minus the path to the
>>> binary you're running, if any). And then CMD is this crazy posix thing
>>> that's one of the others depending on your command line options.
>>
>> compare
>>
>> ./toybox ps -A -T -o pid,tid,comm,command
>>
>> with
>>
>> ps -A -T -o pid,tid,comm,command
> 
> (since it's taken this long and you still don't see what i'm saying, i
> guess i shouldn't assume you're seeing what i'm seeing...
> 
> here's what i see for some random chrome processes with ps:
> 
>  86993  86993 chrome          /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  86997 Chrome_ChildIOT /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  86999 Compositor      /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  87000 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  87001 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  87002 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  87003 CompositorTileW /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  87004 handle-watcher- /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  87005 HTMLParserThrea /opt/google/chrome/chrome --type=renderer --lang=e
>  86993  87008 ScriptStreamerT /opt/google/chrome/chrome --type=renderer --lang=e
>  86993 128020 WorkerPool/5655 /opt/google/chrome/chrome --type=renderer --lang=e
> 
> and then toybox (ignoring that toybox mangled the large tid for the
> last thread):
> 
> 86993 86993 chrome          /opt/google/chrome/chrome (deleted)
> 86993 86997 Chrome_ChildIOT [Chrome_ChildIOT]
> 86993 86999 Compositor      [Compositor]
> 86993 87000 CompositorTileW [CompositorTileW]
> 86993 87001 CompositorTileW [CompositorTileW]
> 86993 87002 CompositorTileW [CompositorTileW]
> 86993 87003 CompositorTileW [CompositorTileW]
> 86993 87004 handle-watcher- [handle-watcher-]
> 86993 87005 HTMLParserThrea [HTMLParserThrea]
> 86993 87008 ScriptStreamerT [ScriptStreamerT]
> 86993 12802 WorkerPool/5655 [WorkerPool/5655]
> 
> )

Sorry, the distraction was actually that when I tried your test I had
that darn "./ps -A doesn't show all processes, but a make clean fixes
it" thing again and I snapshotted the generated/ directory and compared
them and it makes NO sense. (I suspect I overwrite some generated files
with a later build. I still don't have a reproduction sequence.)

Attempting to diff the "objdump -d generated/obj/ps.o" output was...
long and uninformative.

Distracted me from the topic at hand a bit. 99% sure this is a build
dependency issue and not a code issue though. It _is_ reliably fixed by
"make clean", I just... ???

Rob