How to use gdb to debug C1 compiler's internal error?
lesliezhai at llvm.org.cn
Mon Mar 26 15:11:57 UTC 2018
Thanks for your response!
在 2018年03月26日 19:20, Thomas Stüfe 写道:
> On Mon, Mar 26, 2018 at 11:48 AM, Andrew Haley <aph at redhat.com
> <mailto: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
> > 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
> > thanks a lot!
> > 
> 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.
Yes, Fedora's wiki mentions that
And I am able to discover the normal SIGSEGV or SIGBUS with my eyes now :P
Thread 2 "java" received signal SIGSEGV, Segmentation fault.
0x00007fffd8f5319c in ?? ()
> 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
More information about the hotspot-compiler-dev