Linux crash native stacks only have 1 line
Alexander Miloslavskiy
alexandr.miloslavskiy at gmail.com
Tue Apr 7 19:37:42 UTC 2020
On 07.04.2020 19:35, Volker Simonis wrote:
> Sure, why not - you can definitively give it a try. On thing you
> should be aware of is that this code will be usually called from the
> signal handler, when the VM is already crashing. This means that the
> VM may already be in an unstable state and we should be very careful
> in order to not risk another error. You can start by looking at
> ElfDecoder/ElfFile in decoder_elf.hpp/elfFile.hpp which already parses
> an ELF file to get symbol information for a certain address. It has
> the following comment :)
>
> // ElfFile is basically an elf file parser, which can lookup the symbol
> // that is the nearest to the given address.
> // Beware, this code is called from vm error reporting code, when vm is already
> // in "error" state, so there are scenarios, lookup will fail. We want this
> // part of code to be very defensive, and bait out if anything went wrong.
>
> I think what you'll have to do is to find out the frame size of a
> native function and use that for unwinding if you have no FP. But this
> can be tricky because glibc sometimes uses frameless functions. I
> think if you look at gdb's unwinding code you will see that it is
> quite complex.
>
> Please also take into account that using a third party library like
> libunwind is not an option for OpenJDK because of licensing issues.
I looked into default glibc `backtrace()` implementation and found that
it loads libgcc and uses `_Unwind_Backtrace` from it. I understand that
libgcc is expected to be installed on most Linux systems, then.
So it sounds promising to also use `_Unwind_Backtrace` in JDK. What do
you think?
More information about the hotspot-dev
mailing list