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...) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
