从 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$1.run()Ljava/lang/Class;+26
j  java.net.URLClassLoader$1.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

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

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

我希望这行末尾的“V+72”有事可做，但想不通。

Answer 1

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

Hot Licks 在他的评论中已经猜到了，+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”将允许您在字节码偏移量和行之间进行映射。示例中的表格表示

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

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

---

不幸的是，这几乎不会帮助您真正解决错误，因为这显然是在libc.so的本机代码中导致更深层次的错误，在某些memcpy期间 - 这显然收到来自libzip.so的无效指针...