[Toybox] top -H segfault

[Rob Landley]

On 05/25/2016 04:35 PM, enh wrote:
> On Wed, May 25, 2016 at 1:59 PM, enh <enh at google.com> wrote:
>> On Tue, May 24, 2016 at 2:23 PM, Rob Landley <rob at landley.net> wrote:
>>> On 05/23/2016 07:59 PM, enh wrote:
>>>> just running home, so no time to debug further, but in case you
>>>> haven't seen this yet... plain "top -H" is segfaulting for me before
>>>> displaying anything.
>>>
>>> Hmmm, no I hadn't seen that. But I do see that ./toybox top -H isn't
>>> displaying anything when I do that...
>>>
>>> Ah. The active node logic changed and I missed updating a spot. (I
>>> tested it, but nothing I tested used "collate". Oops. I need to work out
>>> how to add this sort of stuff to the test suite. Probably have to use
>>> archival snapshots of "ps" contents to get consistent reproducible test
>>> output...)
>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>                                                     0x00000000004219c1
>>>> in top_common (filter=filter at entry=0x41f738 <merge_deltas>) at
>>>> toys/posix/ps.c:1349
>>>> 1349      if (old.count && (!new.count || *otb->slot < *ntb->slot)) {
>>>
>>> Null dereference on *otb and *ntb because now you traverse the tree in
>>> order and keep each node that has a non-null ->extra field.
>>>
>>> Try now?
>>
>> (sorry, was too busy to get back to this until now...)
>>
>> yes, works for me now, and i probably wouldn't have found that myself
>> in a reasonable amount of time anyway!
>>
>> "toybox top -b -n 1 -o
>> pid,tid,user,pr,ni,%cpu,s,vsz,rss,pcy,command,name -s 6" now looks
>> close enough to what dumpstate wants for bug reports that i can give
>> it a go...
> 
> actually, no, -o COMMAND isn't giving me what i thought. (previously
> i'd only tested on the desktop.) on Android everything shows up as
> /system/bin/app_process64 --- it's the first word of
> readlink('/proc/pid/exe'). (when the zygote forks it sets argv[0] to
> the package name of the app it's about to run, so you can see things
> like "com.android.inputmethod.latin" here.)

Slight awkwardness: TNAME (for "thread name") fits in the help text
column but TCOMMAND doesn't.

Right now NAME is argv[0] with leading path stripped and COMMAND is
argv[0] verbatim, so TNAME would logically be the thread parent's
argv[0] with path stripped.

Would stripping path (if any) be a bad thing here? (I don't have to, I'm
just trying to figure out which behavior is less surprising...)

Rob