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