Re: [Crash-utility] Issues with ps -a/vtop
----- Original Message -----
Hello All,
I ran into this problem were ps –a/vtop can’t access user space.
Looking at the change log it appears a fix was put in as 4.0-3.7. But
I’m seeing this issue with 5.1.3
crash> ps -a 23591
PID: 23591 TASK: ffff8103813be7a0 CPU: 5 COMMAND: "python"
ps: cannot access user stack address: 7fff7d89a75f
crash> vtop 7fff7d89a75f
VIRTUAL PHYSICAL
7fff7d89a75f (not accessible)
This is on a RHEL 5.4 with kernel 2.6.18-194.11.3.el5. What
information will needed to debug this? Or am I using these commands
incorrectly?
Thanks in advance for any help you can give me.
Steven Soulen
Hi Steven,
If the vmcore was post-processed by makedumpfile -- which had filtered
out user-space pages -- then the attempted read of a user stack address
by the "ps -a" command would cause a failure like yours did.
But the vtop command should be able to do a translation down to the
PTE of the "filtered-out" user space page. When "vtop" fails with
the "(not accessible)" message, it means that the virtual address
doesn't fit into any of the current context's VMAs. So when you did
the "vtop 7fff7d89a75f", were you in pid 23591's context? In other
words, you would have to do either this:
crash> set 23591
...
crash> vtop 7fff7d89a75f
...
or alternatively, this:
crash> vtop -c 23591 7fff7d89a75f
Dave