[Crash-utility] Issues with ps -a/vtop

[Dave Anderson]

----- 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