[Toybox] top -H segfault

[enh]

On Thu, May 26, 2016 at 1:03 PM, Rob Landley <rob at landley.net> wrote:
> 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...)

on Android there would never be a path anyway; it'll be a
fully-qualified Java package name. com.facebook.katana or whatever.
(but if you're asking what the old top did, it didn't strip paths. i'm
looking at everyone's favorite, /system/bin/mediaserver, right now :-)
)

> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.