How to use gdb to debug C1 compiler's internal error?

[Thomas Stüfe]

On Mon, Mar 26, 2018 at 11:48 AM, Andrew Haley <aph at redhat.com> wrote:

> On 03/22/2018 04:32 PM, Leslie Zhai wrote:
> > So backtrace or set breakpoint might be helpful for debugging compiling
> > thread, but doesn't work for running thread? I am reading Analyzing and
> > Debugging the HotSpot VM at the OS Level[1] please give me some advice,
> > thanks a lot!
> >
> > [1] http://www.progdoc.de/papers/JavaOne2014/javaone2014_con3138.html
>
> You'll first need to set a breakpoint in the segfault handler here in
> JVM_handle_linux_signal:
>
>   VMError::report_and_die(t, sig, pc, info, ucVoid);
>
> Then you can use gdb to go up the stack to the point of the crash.
>
> At that point you'll be inspecting the stack to see what's there.  If
> you can't tell, then your next plan should be to instrument the code
> you're generating to add tracing information so that when it does, you
> know where you are.
>
>
small addition, until you hit the breakpoint at VMError::report_and_die()
gdb may trip over any number of SIGSEGV or SIGBUS. That is usually normal,
since signals are also used internally for non-error purposes. Just
continue until you hit VMError::report_and_die(), which when you hit it
indicates a real error. Or, set the SIGSEGV handler to nostop.

Best Regards, Thomas


> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180326/ecd38fc3/attachment.html>