Linux crash native stacks only have 1 line

Alexander Miloslavskiy alexandr.miloslavskiy at gmail.com
Tue Apr 7 16:48:27 UTC 2020


> one of the problems may be that the native code you're crashed in was 
> compiled with "-fomit-frame-pointer" which means that the frame pointer 
> register can't be used for unwinding. 

I found that gcc `-O` already implies `-fomit-frame-pointer` [1].
gcc `-O2` includes all optimizations from `-O`.

I have tested that on a small program and confirmed that
1) `-O2` omits frame pointers,
2) `-O2 -fno-omit-frame-pointer` preserves frame pointers.

Since most "production" code is compiled with -O2, this effectively 
means that if native crash occurs outside JRE then crash log will fail 
to unwind stack :(

In my case, most crashes occur in GTK or GLib, both omit frame pointers.

> I you already managed to attach gdb and get a correct back trace at the 
> point where your program crashes, you can just as well debug the HotSpot 
> stack tracing routine "print_native_stack()" in the file "debug.cpp" to 
> see what's the actual problem :)

I didn't debug because I understand that JDK can't unwind stack without 
frame pointers.

> Before doing  that, I'd check your 
> reproducer with jdk14 or better the tip revision just to make sure 
> you're not hunting a problem which has already been fixed upstream.

I have tested with JDK14+36 and alas, no changes.

> In general it's always advisable to mention the exact jdk version and 
> distribution you've used.

Sorry, didn't mention because I observed this on all JDK's from JDK8 to 
JDK13 (now also confirmed on JDK14)

I think I could try to implement better stack walking. Is there any 
interest to accept such patches, provided that they pass code review?

[1] 
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options


More information about the hotspot-dev mailing list