----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
