Hi Yasumasa,

Actually I intentionally decided to take this approach no matter what the cause of the failure. If we can't get the registers, print a WARNING, and then SA stack walking code will use the fall back of last_java_frame if available, otherwise not produce a stack trace.

thanks,

Chris

On 6/17/20 5:11 PM, Yasumasa Suenaga wrote:
Hi Chris,

Can you handle ESRCH only in this case?
ptrace(2) might fail by other reason.


Thanks,

Yasumasa


On 2020/06/18 5:34, Chris Plummer wrote:
Hello,

Please help review the following:

https://bugs.openjdk.java.net/browse/JDK-8247533
http://cr.openjdk.java.net/~cjplummer/8247533/webrev.00/index.html

The CR contains all the needed details. Here's a summary of changes in each file:

src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp
src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp
-Instead of throwing an exception when the OS ThreadID is invalid, print a warning.

src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c
-Improve a print_debug message

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThread.java src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java -Deal with the array of registers read in being null due to the OS ThreadID not being valid.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java -Fix issue with "sun.jvm.hotspot.debugger.DebuggerException" appearing twice when printing the exception.

thanks,

Chris

Reply via email to