How to use gdb to debug C1 compiler's internal error?
thomas.stuefe at gmail.com
Mon Mar 26 11:20:26 UTC 2018
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 please give me some advice,
> > thanks a lot!
> >  http://www.progdoc.de/papers/JavaOne2014/javaone2014_con3138.html
> You'll first need to set a breakpoint in the segfault handler here in
> 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...
More information about the hotspot-compiler-dev