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文件。有没有办法使用致命错误日志中的信息识别源代码中的行号？

我希望这个＆＃34; V + 72＆＃34;在行的末尾有事可做，但无法弄清楚。

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 for将字节码偏移量映射到源代码中的实际行数字 ）

不幸的是，这几乎无法帮助您真正解决错误，因为在libc.so的本机代码中，这个问题显然会导致某些级别更深一些memcpy } - 显然从libzip.so ...
收到了无效指针

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

1 个答案: