On Thu, May 26, 2016 at 1:03 PM, Rob Landley <[email protected]> wrote: > On 05/25/2016 04:35 PM, enh wrote: >> On Wed, May 25, 2016 at 1:59 PM, enh <[email protected]> wrote: >>> On Tue, May 24, 2016 at 2:23 PM, Rob Landley <[email protected]> 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@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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
