According to 2.7 Stack Unwind Algorithm in System V Application Binary Interface AMD64 Architecture Processor Supplement [1], we need to use DWARF in .eh_frame or .debug_frame for stack unwinding.
AsJDK-8022183 said, omit-frame-pointer is enabled by default since GCC 4.6, so system library (e.g. libc) might be compiled with this feature.
However `jhsdb jstack --mixed` does not do so, it uses base pointer register (RBP). So it might be lack of stack frames.
For example, if we get native stack trace from LongSleep.java, it do not work well.
LongSleep.java
```
public class LongSleep{
public static void main(String[] args) throws Exception{
Thread.sleep(3600000);
}
}
```
jhsdb jstack --mixed on JDK 13
```
----------------- 193838 -----------------
"main" #1 prio=5 tid=0x00007fe748017800 nid=0x2f52e waiting on condition [0x00007fe74c46e000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
JavaThread state: _thread_blocked
0x00007fe74dc5107a __pthread_cond_timedwait + 0x25a
```
It should be as below:
```
----------------- 193957 -----------------
"main" #1 prio=5 tid=0x00007fd1ec021000 nid=0x2f5a5 waiting on condition [0x00007fd1f3cd6000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
JavaThread state: _thread_blocked
0x00007fd1f634607a __pthread_cond_timedwait + 0x25a
0x00007fd1f55711a8 os::PlatformEvent::park(long) + 0x138
0x00007fd1f598ea87 JavaThread::sleep(long) + 0x307
0x00007fd1f5036ad6 JVM_Sleep + 0x1d6
0x00007fd1d465fdbe * java.lang.Thread.sleep(long) bci:0 (Interpreted frame)
0x00007fd1d464d9ca <StubRoutines>
0x00007fd1f4e9208c JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac
0x00007fd1f4e9208c JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac
0x00007fd1f4f70609 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.0] [clone .constprop.0] + 0x409
0x00007fd1f4f97fa9 jni_CallStaticVoidMethod + 0x1f9
0x00007fd1f635dc6e JavaMain + 0xbee
0x00007fd1f6361299 ThreadJavaMain + 0x9
```
I guessJDK-8219201 is caused by same issue.
[1] https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf
As
However `jhsdb jstack --mixed` does not do so, it uses base pointer register (RBP). So it might be lack of stack frames.
For example, if we get native stack trace from LongSleep.java, it do not work well.
LongSleep.java
```
public class LongSleep{
public static void main(String[] args) throws Exception{
Thread.sleep(3600000);
}
}
```
jhsdb jstack --mixed on JDK 13
```
----------------- 193838 -----------------
"main" #1 prio=5 tid=0x00007fe748017800 nid=0x2f52e waiting on condition [0x00007fe74c46e000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
JavaThread state: _thread_blocked
0x00007fe74dc5107a __pthread_cond_timedwait + 0x25a
```
It should be as below:
```
----------------- 193957 -----------------
"main" #1 prio=5 tid=0x00007fd1ec021000 nid=0x2f5a5 waiting on condition [0x00007fd1f3cd6000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
JavaThread state: _thread_blocked
0x00007fd1f634607a __pthread_cond_timedwait + 0x25a
0x00007fd1f55711a8 os::PlatformEvent::park(long) + 0x138
0x00007fd1f598ea87 JavaThread::sleep(long) + 0x307
0x00007fd1f5036ad6 JVM_Sleep + 0x1d6
0x00007fd1d465fdbe * java.lang.Thread.sleep(long) bci:0 (Interpreted frame)
0x00007fd1d464d9ca <StubRoutines>
0x00007fd1f4e9208c JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac
0x00007fd1f4e9208c JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac
0x00007fd1f4f70609 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.0] [clone .constprop.0] + 0x409
0x00007fd1f4f97fa9 jni_CallStaticVoidMethod + 0x1f9
0x00007fd1f635dc6e JavaMain + 0xbee
0x00007fd1f6361299 ThreadJavaMain + 0x9
```
I guess
[1] https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf
- duplicates
-
JDK-8219201 SA: jstack in mixed mode does not print the full stack trace for all the threads
-
- Closed
-
- relates to
-
JDK-8245234 Still seeing missing mixed stack traces, even after JDK-8234624
-
- Open
-
-
JDK-8240956 SEGV in DwarfParser::process_dwarf after JDK-8234624
-
- Closed
-
-
JDK-8300032 DwarfParser resource leak
-
- Resolved
-
-
JDK-8022183 GCC 4.6 changes default setting for omit-frame-pointer which breaks hotspot stack walking
-
- Closed
-
-
JDK-8219086 SA: jstack in mixed mode truncates the stack trace
-
- Closed
-
(1 relates to)