> Playing with MDB ::ps dcmd I noticed that the status field interpretation is
> different from the regular ps(1) command. The status in MDB is the value of
> pr.p_stat field which, according to the code may only have values SRUN, SIDL
> and SZOMB. The code in MDB pretends to understand other states:
>
> static char
> pstat2ch(uchar_t state)
> {
> switch (state) {
> case SSLEEP: return ('S');
> case SRUN: return ('R');
> case SZOMB: return ('Z');
> case SIDL: return ('I');
> case SONPROC: return ('O');
> case SSTOP: return ('T');
> default: return ('?');
> }
> }
>
> The ps(1) and prstat(1M) get process state from psinfo_t pr_sname field which
> is based on thread state for the representative lwp and which may be
> different
> from p_stat field.
>
> The MDB implementation is quite simple since it just reads p_stat field from
> the process structure and doesn't need to simulate any translations done by
> /proc.
>
> The question, though is whether such discrepancy is by design or by accident?
>
> - Alex Kolbasov
pr_sname can't be computed normally by mdb, since the notion of selecting
a representative LWP according to proc(4) rules is impossible from a dump
or live kernel image. So I just printed p_stat. The only other real
possible choice is ? for everything except zombies, leaving users to go
and query individual LWPs (::thread) if they want to see what is going on.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
