从 JVM 致命错误日志中猜测方法行号

Question

我有一个没有核心转储的致命错误日志，需要查明原因。这是在 .log 文件中找到的堆栈：

# Problematic frame:
# C  [libc.so.6+0x7b4bb]  memcpy+0x15b

{...}

Stack: [0x00002ac8c4d2c000,0x00002ac8c4e2d000],  sp=0x00002ac8c4e28ef8,  free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x7b4bb]  memcpy+0x15b
C  [libzip.so+0x50b0]  ZIP_GetEntry+0xd0
C  [libzip.so+0x3eed]  Java_java_util_zip_ZipFile_getEntry+0xad
J 28  java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00002ac8acf404ee [0x00002ac8acf40420+0xce]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 28  java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00002ac8acf40478 [0x00002ac8acf40420+0x58]
J 33 C2 java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; (86 bytes) @ 0x00002ac8acf45548 [0x00002ac8acf45480+0xc8]
J 58 C2 java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry; (9 bytes) @ 0x00002ac8acf4e828 [0x00002ac8acf4e7e0+0x48]
J 44 C2 sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; (91 bytes) @ 0x00002ac8acf47168 [0x00002ac8acf47100+0x68]
J 34 C2 sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; (74 bytes) @ 0x00002ac8acf41f70 [0x00002ac8acf41f00+0x70]
j  java.net.URLClassLoader.run()Ljava/lang/Class;+26
j  java.net.URLClassLoader.run()Ljava/lang/Object;+1
v  ~StubRoutines::call_stub
j  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j  java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13
j  java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70
j  sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36
j  java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3
v  ~StubRoutines::call_stub
j  com.smackdapp.SmackHandler.handleRequest(Ljava/lang/String;Lorg/eclipse/jetty/server/Request;Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+72

正如我在另一个 Whosebug 答案中读到的那样，这可能是替换 jvm 需要加载的任何 .jar 时的常见错误（或硬件内存错误）。

我想猜测的是导致此致命错误的 .jar 文件。有没有什么方法可以用致命错误日志中的信息来识别我的源代码中的行号？

我希望行尾的这个 "V+72" 能有所作为，但想不通。

Answer 1

这可能最终无法解决问题，但它回答了部分问题：

正如在他的评论中已经猜到的那样，+72 只是字节码偏移量。我用一个小程序对此进行了测试：

^{（否则不相关，只是从另一个问题中快速获得）}

class TestNativeArray3D
{
    public static void main(String args[])
    {
        System.loadLibrary("TestNativeArray3D");
        int terrain[][][] = genTerrain(123, 8, 6);
    }
    private native static int[][][] genTerrain(int seed, int x, int y);
}

本机 genTerrain 函数通过调用

公然创建任意错误

jclass errorClass = env->FindClass("XXX");
env->NewObjectArray(10, errorClass, NULL);

导致核心转储。

堆栈如下所示：

Stack: [0x0000000002500000,0x0000000002600000],  sp=0x00000000025ff4e0,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x14ebb6]
C  [TestNativeArray3D.dll+0x397d]  JNIEnv_::NewObjectArray+0x4d
C  [TestNativeArray3D.dll+0x3ae8]  Java_TestNativeArray3D_genTerrain+0x98
C  0x0000000002715534

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  TestNativeArray3D.genTerrain(III)[[[I+0
j  TestNativeArray3D.main([Ljava/lang/String;)V+11
v  ~StubRoutines::call_stub

这里，类似地包含（可能的）偏移量的行是

j TestNativeArray3D.main([Ljava/lang/String;)V+11

使用

反编译class文件时

javap -c -l TestNativeArray3D

（注意-l（小"L"）获取行号！）输出为

class TestNativeArray3D {
  TestNativeArray3D();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return
    LineNumberTable:
      line 3: 0

  public static void main(java.lang.String[]);
    Code:
       0: ldc           #2                  // String TestNativeArray3D
       2: invokestatic  #3                  // Method java/lang/System.loadLibrary:(Ljava/lang/String;)V
       5: bipush        123
       7: bipush        8
       9: bipush        6
      11: invokestatic  #4                  // Method genTerrain:(III)[[[I
      14: astore_1
      15: return
    LineNumberTable:
      line 7: 0
      line 8: 5
      line 9: 15
}

实际上，本机调用发生在偏移 11 处。（是的，我通过在此调用之前添加一些进一步的代码来对此进行反检查：核心转储中的偏移量相应地发生变化）。

"LineNumberTable" 将允许您在字节码偏移量和行之间进行映射。示例中的 table 表示

源代码第7行对应字节码偏移量0，
源代码第8行对应字节码偏移量5，
源代码第9行对应字节码偏移量15

所以这里的关键指令与代码行 8 相关。（在这种情况下，这很明显，因为这直接是 invokestatic 调用。我只是想指出，您可以查看LineNumberTable 用于字节码偏移量到源代码实际行编号的映射)

不幸的是，这很难帮助您真正解决错误，因为这个错误显然在 libc.so 的本机代码中引起了更深层次的错误，一些 memcpy - 显然从 libzip.so...

接收到无效指针

从 JVM 致命错误日志中猜测方法行号

Guess method line number from JVM fatal error log

java

jvm

jvm-crash