Backtrace中缺少gdb符号?

时间:2015-06-03 10:39:28

标签: java gdb

我正在运行此测试,因为我想查看程序的堆栈跟踪。 以下是我的计划:

 public class NanoTime {
 public static void main (String[] args) {   
      long StartTime = System.nanoTime();
      StringBuffer buffer = new StringBuffer();
      for(int i=0; i<1000; i++) {   
         buffer.append("a");  }
      long EndTime = System.nanoTime();
      long totalTime = EndTime-StartTime;
      System.out.println("Total time of calculation ="+ totalTime);   
 }

}

现在我使用的是使用调试级别设置的OpenJDK来缓慢调试,还有另一个设置为fastdebug。 我得到了这个输出:

[New Thread 0x7ffff7fd3700 (LWP 22532)]

 Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fd3700 (LWP 22532)]0x00007fffe10002b4 in ?? ()
(gdb) bt
#0  0x00007fffe10002b4 in ?? ()
#1  0x0000000000000202 in ?? ()
#2  0x00007fffe1000160 in ?? ()
#3  0x00007ffff66bd1a9 in execute_internal_vm_tests () at /home/bionix/Openjdk8/hotspot/src/share/vm/prims/jni.cpp:5128
#4  0x00007ffff7fd2550 in ?? ()
#5  0x00007ffff6b08bf8 in VM_Version::get_cpu_info_wrapper () at /home/bionix/Openjdk8/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:395
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

我对那里的问号感到困惑,因为我期望本机方法名称。

注意:我甚至禁用了JIT编译器:gdb --args java -Xint Test

2 个答案:

答案 0 :(得分:1)

在普通代码中,gdb依赖于调试信息(以及较小程度上的&#34;链接器&#34;符号)来查找函数的名称,因为它展开。调试信息在各种标准中描述,DWARF是当前最适合Linux的标准。编译器发出调试信息,然后由gdb读取。

对于像OpenJDK这样的即时编译器,没有商定的解决方案来为调试器发出读取调试信息。因此,正如您所发现的那样,gdb通常不知道发生了什么。

事实上,正如您从跟踪中看到的那样,gdb甚至无法真正解开整个堆栈。这意味着什么:

  

Backtrace已停止:此框架内部的前一帧(损坏的堆栈?)

现代编译器和ABI往往需要一些额外的调试信息才能解开 - 而且,对于如何对JIT编译起作用还没有达成一致意见。当这些信息不可用时,GDB有一些尝试放松的尝试,但正如你所看到的,它们有时会失败。

所以,那是坏消息。

好消息是gdb提供了一些为JIT编写unwinders和调试信息阅读器的方法。并且,有人正在为OpenJDK工作。我无法快速找到来源,但我确实找到this thread来解释它。

答案 1 :(得分:0)

这是因为jvm正在使用模板解释器。对于该解释器,java字节码处理程序在开始时间内被翻译成当前平台的机器指令。您仍然可以获得完整的堆栈跟踪,更多信息:template interpreter demo

还有cpp解释器,这是你期望在堆栈跟踪中看到的解释器。但是不再支持cpp解释器,只能使用零jvm变体。

还有关于口译员的article