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

Thomas Stüfe thomas.stuefe at
Mon Mar 26 11:20:26 UTC 2018

On Mon, Mar 26, 2018 at 11:48 AM, Andrew Haley <aph at> 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]
> 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. <>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-compiler-dev mailing list