Richard L. Hamilton wrote:
[...]
To get around the problem
pmap: cannot examine 5608: address space is
changing
and get a closer look, try stopping the process
first:
pstop 5608
and then running pmap or whatever to inspect it,
and finally running
prun 5608
to let it run again.
Why is pmap not doing this?
I don't know. I (a) don't work for Sun, and (b) only run
OpenSolaris under VirtualBox on an Intel Mac Mini (my other
systems are SPARC and running Solaris 9, and Solaris SXCE snv_97,
respectively). So just starting OpenSolaris under VirtualBox uses
about all the time I'm willing to spend getting my answer right
on anything but the most interesting problems. I would _guess_ that
either using the -F option might also help
-F Force. Grabs the target process even if
another process has control.
You could also try -L, since (apart from changing the output), this
seems to change the way the data is collected via an agent LWP inside
the process itself, and possibly involving stopping the process. Like
Richard, I cannot say for sure though.
As for the default behavior, the presence of the "address space is
changing" message and the fact that the code loops with "#define
MAX_RETRIES 5" implies that the process is definitely not stopped and
that the possibility of change is expected.
The code that handles -L with an agent LWP, on the other hand, goes to
some effort to buffer stdout to avoid the deadlock you'd get with "pmap
`pgrep xterm`" from inside the relevant xterm nad has comments about the
process being blocked. Running pmap on the X server you're issuing pmap
on being a well known way to lock up your desktop session ...
Hugh.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
