Hi,

We've a module that fetches the process information of specific
process on Sun Solaris platform. The application (Java) runs in 32 bit
JRE. It has JNI that fetches the data from psinfo file of the specific
process from /proc/<pid>/ directory. In its current shape it is not
able to fetch the memory related information of a 64 bit process. This
is due to the size_t attribute is 8 bytes (unsigned long) and our
application runs in 32 bit mode which tries to read 4 bytes as size_t
in 32 bit mode is 4 bytes  long.

The psinfo structure looks like this

typedef struct psinfo {
    int pr_flag;              /* process flags (DEPRECATED: see below)
*/
    int pr_nlwp;              /* number of active lwps in the process
*/
    int pr_nzomb;             /* number of zombie lwps in the process
*/
    pid_t pr_pid;             /* process id */
    pid_t pr_ppid;            /* process id of parent */
    pid_t pr_pgid;            /* process id of process group leader */
    pid_t pr_sid;             /* session id */
    uid_t pr_uid;             /* real user id */
    uid_t pr_euid;            /* effective user id */
    gid_t pr_gid;             /* real group id */
    gid_t pr_egid;            /* effective group id */
    uintptr_t pr_addr;        /* address of process */
    size_t pr_size;           /* size of process image in Kbytes */
    size_t pr_rssize;         /* resident set size in Kbytes */
    dev_t pr_ttydev;          /* controlling tty device (or PRNODEV)
*/
    ushort_t pr_pctcpu;       /* % of recent cpu time used by all lwps
*/
    ushort_t pr_pctmem;       /* % of system memory used by process */
    timestruc_t pr_start;     /* process start time, from the epoch */
    timestruc_t pr_time;      /* cpu time for this process */
    timestruc_t pr_ctime;     /* cpu time for reaped children */
    char pr_fname[PRFNSZ];    /* name of exec'ed file */
    char pr_psargs[PRARGSZ];  /* initial characters of arg list */
    int pr_wstat;             /* if zombie, the wait() status */
    int pr_argc;              /* initial argument count */
    uintptr_t pr_argv;        /* address of initial argument vector */
    uintptr_t pr_envp;        /* address of initial environment vector
*/
    char pr_dmodel;           /* data model of the process */
    lwpsinfo_t pr_lwp;        /* information for representative lwp */
    taskid_t pr_taskid;       /* task id */
    projid_t pr_projid;       /* project id */
    poolid_t pr_poolid;       /* pool id */
    zoneid_t pr_zoneid;       /* zone id */
    ctid_t pr_contract;       /* process contract id */
} psinfo_t;

In this pr_size and pr_rsize specifies the virtual size and resident
size of the process being run. For 64 bit processes when read from 32
bit binary returns zero.

Tried to correctly offset to the correct position and reading 8 bytes
each into 'unsigned long long' variables respectively but still it
returns 0. Is there any tweaks we can use to get these two attributes
correctly when the compiled code is with 32 bit architecture. We donot
want to move to 64 bit mode right now for this as there are other
constraints. If nothing works, we are looking at fetching the same
from running ps command and reading its output. But since this looks
crude, we are looking at some other elegant way of getting the same.
Please help.

Thanks and Regards,
Krishna

In article <84684da4-1697-4eae-9663-917f44dee371@q5g2000prf.googlegroups.com>,
	Krishna <nkrishnamurthy@gmail.com> writes:
> 
> In this pr_size and pr_rsize specifies the virtual size and resident
> size of the process being run. For 64 bit processes when read from 32
> bit binary returns zero.

In the proc filesystem...

        /*
         * If we are looking at an LP64 process, zero out
         * the fields that cannot be represented in ILP32.
         */
        if (p->p_model != DATAMODEL_ILP32) {
                psp->pr_size = 0;
                psp->pr_rssize = 0;
                psp->pr_argv = 0;
                psp->pr_envp = 0;
        }

> Tried to correctly offset to the correct position and reading 8 bytes
> each into 'unsigned long long' variables respectively but still it
> returns 0.

A 32 bit process sees a different psinfo structure from a 64 bit
process, and you don't have 8 bytes there to read.

> Is there any tweaks we can use to get these two attributes
> correctly when the compiled code is with 32 bit architecture. We donot
> want to move to 64 bit mode right now for this as there are other
> constraints. If nothing works, we are looking at fetching the same
> from running ps command and reading its output. But since this looks
> crude, we are looking at some other elegant way of getting the same.

I think you will have to fork off a 64 bit process (such as ps(1)
or something you write just for the purpose.

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

On Jul 25, 5:06 pm, and...@cucumber.demon.co.uk (Andrew Gabriel)
wrote:
> In article <84684da4-1697-4eae-9663-917f44dee...@q5g2000prf.googlegroups.com>,
>         Krishna <nkrishnamur...@gmail.com> writes:
>
>
>
> > In this pr_size and pr_rsize specifies the virtual size and resident
> > size of the process being run. For 64 bit processes when read from 32
> > bit binary returns zero.
>
> In the proc filesystem...
>
>         /*
>          * If we are looking at an LP64 process, zero out
>          * the fields that cannot be represented in ILP32.
>          */
>         if (p->p_model != DATAMODEL_ILP32) {
>                 psp->pr_size = 0;
>                 psp->pr_rssize = 0;
>                 psp->pr_argv = 0;
>                 psp->pr_envp = 0;
>         }
>
> > Tried to correctly offset to the correct position and reading 8 bytes
> > each into 'unsigned long long' variables respectively but still it
> > returns 0.
>
> A 32 bit process sees a different psinfo structure from a 64 bit
> process, and you don't have 8 bytes there to read.
>
> > Is there any tweaks we can use to get these two attributes
> > correctly when the compiled code is with 32 bit architecture. We donot
> > want to move to 64 bit mode right now for this as there are other
> > constraints. If nothing works, we are looking at fetching the same
> > from running ps command and reading its output. But since this looks
> > crude, we are looking at some other elegant way of getting the same.
>
> I think you will have to fork off a 64 bit process (such as ps(1)
> or something you write just for the purpose.
>
> --
> Andrew Gabriel
> [email address is not usable -- followup in the newsgroup]

Thanks Andrew for the response.

I've one additional clarification.

When the code is compiled in 64 bit mode, the memory related values
are returned properly. What we're trying is open the /proc/<pid>/
psinfo file, offset to the location and trying to read 8 bytes of
data. And same in the case of when the module is compiled in 32 bit
mode and trying to read 8 bytes of data into 'unsigned long long' and
it's returning zero. Is is due to the fact that 'unisigned long' from
64 bit cannot be mapped to 32 bit 'unsigned long long' or am i missing
something? Please le t me know.

Thanks,
Krishna