1. 首页
  2. 问答
  3. JVM在类加载期间memcpy崩溃

JVM在类加载期间memcpy崩溃

2009-08-21 216 views
13

我的JVM崩溃了，并且hs_err文件显示它在尝试加载类时崩溃。特别是在尝试memcpy（[libc.so.6 + 0x6aa2c] memcpy + 0x1c）时。我查看了.class文件，并能够确定正在加载哪个类。JVM在类加载期间memcpy崩溃

但是，任何人都可以告诉我什么可能会导致这种情况，或者我可以如何确定更多的原因？如果JVM内存不足，它不会抛出错误。任何见解都非常感谢。

我已经包含了我的hs_err文件的摘录。

# 
# An unexpected error has been detected by Java Runtime Environment: 
# 
# SIGBUS (0x7) at pc=0x005aba2c, pid=20841, tid=2427227056 
# 
# Java VM: Java HotSpot(TM) Client VM (1.6.0_02-b05 mixed mode) 
# Problematic frame: 
# C [libc.so.6+0x6aa2c] memcpy+0x1c 
# 
# If you would like to submit a bug report, please visit: 
# http://java.sun.com/webapps/bugreport/crash.jsp 
# 

--------------- T H R E A D --------------- 

Current thread (0x90d0dc00): JavaThread "ORDERHANDLER" [_thread_in_native, id=20881] 

siginfo:si_signo=7, si_errno=0, si_code=2, si_addr=0x915e3000 

Registers: 
EAX=0x91218298, EBX=0xb7f2e71c, ECX=0x0000079b, EDX=0x915dfef2 
ESP=0x90ac6a34, EBP=0x90ac6a60, ESI=0x915e2ffd, EDI=0x914f0a0d 
EIP=0x005aba2c, CR2=0x915e3000, EFLAGS=0x00010206 

Top of Stack: (sp=0x90ac6a34) 
0x90ac6a34: b7f29d4b 914ed930 915dff20 00004f49 
0x90ac6a44: 082e7bc4 00006f6f 00004243 00004f49 
0x90ac6a54: b7f2e71c 080e3e54 00000000 90ac6a90 
0x90ac6a64: b7f29fbb 080e3b00 080e3e54 00000000 
0x90ac6a74: 00000000 90d0dc00 00000000 d68dd1b6 
0x90ac6a84: b7f2e71c 90ac6ad8 90d0dcec 90ac6f00 
0x90ac6a94: b7f21169 080e3b00 90ac6ad8 0000002b 
0x90ac6aa4: 0000002b 90ac6ad8 00000008 00000000 

Instructions: (pc=0x005aba2c) 
0x005aba1c: 8b 74 24 08 fc d1 e9 73 01 a4 d1 e9 73 02 66 a5 
0x005aba2c: f3 a5 89 c7 89 d6 8b 44 24 04 c3 90 90 90 90 90 

Stack: [0x90a78000,0x90ac9000), sp=0x90ac6a34, free space=314k 
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 
C [libc.so.6+0x6aa2c] memcpy+0x1c 
C [libzip.so+0xbfbb] ZIP_GetEntry+0x10b 
C [libzip.so+0x3169] Java_java_util_zip_ZipFile_getEntry+0xc9 
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J 
J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; 
J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; 
J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; 
J sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; 
J java.net.URLClassLoader$1.run()Ljava/lang/Object; 
v ~StubRoutines::call_stub 
V [libjvm.so+0x20bbbd] 
V [libjvm.so+0x30a6b8] 
V [libjvm.so+0x20ba50] 
V [libjvm.so+0x26190b] 
C [libjava.so+0xaa5c] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x3 
c 
J java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; 
J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class; 
J java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; 
J sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; 
j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 
j java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 
v ~StubRoutines::call_stub 
V [libjvm.so+0x20bbbd] 
V [libjvm.so+0x30a6b8] 
V [libjvm.so+0x20b6e1] 
V [libjvm.so+0x20b7ca] 
V [libjvm.so+0x367621] 
V [libjvm.so+0x3662a5] 
V [libjvm.so+0x365357] 
V [libjvm.so+0x365112] 
V [libjvm.so+0x1adb03] 
V [libjvm.so+0x1aeb32] 
V [libjvm.so+0x2d75cb] 
V [libjvm.so+0x2d8a94] 
V [libjvm.so+0x2d8a17] 
V [libjvm.so+0x1fe7f8] 
j com.aqua.foms.book.OrderHandler.handleNewOrder(Lcom/aqua/NmsApi/OrderMap;Lcom/aqua/api/AtsMessage;)V+221 
j com.aqua.foms.book.FMSNewOrderTask.execute()V+12 
j com.aqua.api.EEDefaultWorkerThread.run()V+96 
v ~StubRoutines::call_stub 
V [libjvm.so+0x20bbbd] 
V [libjvm.so+0x30a6b8] 
V [libjvm.so+0x20b4d0] 
V [libjvm.so+0x20b55d] 
V [libjvm.so+0x27b795] 
V [libjvm.so+0x383ef0] 
V [libjvm.so+0x30b5a9] 
C [libpthread.so.0+0x5371] 

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) 
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J 
J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; 
J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; 
J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; 
J sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; 
J java.net.URLClassLoader$1.run()Ljava/lang/Object; 
v ~StubRoutines::call_stub 
J java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; 
J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class; 
J java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; 
J sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; 
j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 
j java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 
v ~StubRoutines::call_stub 
j com.aqua.foms.book.OrderHandler.handleNewOrder(Lcom/aqua/NmsApi/OrderMap;Lcom/aqua/api/AtsMessage;)V+221 
j com.aqua.foms.book.FMSNewOrderTask.execute()V+12 
j com.aqua.api.EEDefaultWorkerThread.run()V+96 
v ~StubRoutines::call_stub 

--------------- P R O C E S S --------------- 

Java Threads: (=> current thread) 
    0x080c9c00 JavaThread "pool-1-thread-3" [_thread_blocked, id=18725] 
    0x0824f800 JavaThread "pool-1-thread-2" [_thread_blocked, id=13693] 
    0x91217c00 JavaThread "AquaSchedulerService_7" daemon [_thread_blocked, id=23675] 
    0x91215c00 JavaThread "AquaSchedulerService_6" daemon [_thread_blocked, id=23001] 
0x91215400 JavaThread "AquaSchedulerService_5" daemon [_thread_blocked, id=22759] 
    0x91213400 JavaThread "AquaSchedulerService_4" daemon [_thread_blocked, id=22410] 
    0x91212c00 JavaThread "AquaSchedulerService_3" daemon [_thread_blocked, id=22262] 
    0x08316400 JavaThread "pool-1-thread-1" [_thread_blocked, id=22260] 
    0x0827d000 JavaThread "JmsConn_1_sender_0" daemon [_thread_blocked, id=21196] 
    0x90d0cc00 JavaThread "Timer-0" [_thread_blocked, id=20882] 
=>0x90d0dc00 JavaThread "ORDERHANDLER" [_thread_in_native, id=20881] 
    0x90d0d400 JavaThread "TradeInviteMonitor" [_thread_blocked, id=20880] 
    0x90d09c00 JavaThread "ROUTERT" [_thread_blocked, id=20878] 
    0x90d09000 JavaThread "TIBCO EMS Session Dispatcher (33197)" [_thread_blocked, id=20877] 
    0x08310800 JavaThread "DORDERHANDLER" [_thread_blocked, id=20874] 
    0x90d01c00 JavaThread "Thread-12" daemon [_thread_blocked, id=20873] 
    0x90d03000 JavaThread "Thread-11" daemon [_thread_in_native, id=20872] 
    0x082e1c00 JavaThread "DELAYEDORDMON" [_thread_blocked, id=20871] 
    0x082e8000 JavaThread "DBUPD" [_thread_blocked, id=20870] 
    0x914e5000 JavaThread "pool-2-thread-1" [_thread_blocked, id=20869] 
    0x914e3c00 JavaThread "StatusStatsEventDispatcherThread" [_thread_blocked, id=20868] 
    0x082c8400 JavaThread "TimerQueue" daemon [_thread_blocked, id=20866] 
    0x082ca000 JavaThread "MDATATHREAD" [_thread_blocked, id=20865] 
    0x082c9400 JavaThread "AquaSchedulerService_2" daemon [_thread_blocked, id=20864] 
    0x9122b000 JavaThread "DestroyJavaVM" [_thread_blocked, id=20843] 
    0x91200800 JavaThread "FirmMatchingServer" [_thread_blocked, id=20863] 
    0x914de800 JavaThread "TIBCO EMS TCPLink Reader (32084)" daemon [_thread_in_native, id=20861] 
    0x9122a400 JavaThread "TIBCO EMS Connections Pinger" daemon [_thread_blocked, id=20859] 
    0x914d4000 JavaThread "WDISTQ" [_thread_blocked, id=20858] 
    0x9121f400 JavaThread "JmsConn_1_connector_0" daemon [_thread_blocked, id=20857] 
    0x914d8000 JavaThread "JmsConn_1_receiver_0" daemon [_thread_blocked, id=20856] 
    0x9149ac00 JavaThread "AquaSchedulerService_1" daemon [_thread_blocked, id=20855] 
    0x9149b400 JavaThread "AquaSchedulerService_0" daemon [_thread_blocked, id=20854] 
    0x9142a000 JavaThread "MySQL Statement Cancellation Timer" daemon [_thread_blocked, id=20852] 
    0x91425c00 JavaThread "Dispatcher-Thread-0" daemon [_thread_blocked, id=20851] 
    0x080bf800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=20849] 
    0x080bdc00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20848] 
    0x080bcc00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20847] 
    0x080a9800 JavaThread "Finalizer" daemon [_thread_blocked, id=20846] 
    0x080a8800 JavaThread "Reference Handler" daemon [_thread_blocked, id=20845] 

Other Threads: 
    0x080a5400 VMThread [id=20844] 
    0x080c1000 WatcherThread [id=20850] 

VM state:not at safepoint (normal execution) 

VM Mutex/Monitor currently owned by a thread: None

来源

2009-08-21 richs

回答

22

我们已经看到类似的错误。我们目前的嫌疑人是在进程运行时被重写（通过升级过程）的jar文件。

来源

2009-08-21 19:19:35 james

+0

这是它:) - 谢谢 – richs 2009-08-21 20:19:43

1

除了普通的ol以外。 JVM中的错误（升级到最新版本，希望它不会再发生） - 或者一些错误的3.使用JNI的派对库，还有其他两个“有趣”的东西可能会导致这种情况。

  1. 硬件故障 - 坏的内存通常是一个很好的候选人加时赛损坏的文件系统可能会导致片状驱动器可能是罪魁祸首了。

  2. 如果您在Solaris上运行，那么如果在JVM将jar/class文件映射到JVM的情况下JVM需要访问该类/ jar文件时，该类/ jar文件以某种方式被截断，您可能会收到SIGBUS错误。

来源

2009-08-21 18:37:14 nos

+0

“不知何故被截断的类/ jar文件”似乎是有道理的;当我尝试删除一个jar文件，我得到一个 [错误]未能执行目标org.apache.maven.plugins：Maven的清理插件：2.4.1： 干净（默认清洁）项目MyProject的：失败清理项目：无法删除 C：\用户\ tshrestha \ MyProject的\目标\ MyProject的-1.0-SNAPSHOT.jar - > [求助1] – 2012-01-05 17:12:07

14

答案1是正确的。 java.util.zip。*的实现存在错误。

如果您替换Java程序当前具有“打开”（已缓存ZipFile/JarFile对象）的zip/jar文件，它将使用从原始文件读取的缓存目录（TOC）数据，并会尝试使用它来解压替换文件中的数据。通货膨胀代码不健壮，并且在出现不良数据时会彻底崩溃。

正常的unix程序在文件处理时保持打开状态。如果覆盖该文件，则使用该文件的程序仍然可以访问它打开的原始文件，凭借打开的文件描述符。

OpenJDK的java.util.zip。*实现选择不保留打开zip/jar文件的文件描述符。其中一个原因可能是，Java通常会在类路径中使用数百个jar文件进行调用，并且设计人员不希望单独使用jar文件中的数百个文件描述符，因此程序本身不会留下任何文件描述符。因此，他们在阅读jar/zip目录后立即关闭文件描述符，并在其内容更改时永久失去对原始jar/zip文件的访问权限。

无论出于何种原因，ZipFile不会或不能告诉zip/jar文件已更改。如果确实如此，它可能会重新读取TOC或发生某种错误，如果这是不可能的。

此外，即使TOC保持有效，这也是一个问题，即充气器在故障数据上崩溃。如果ZIP目录是有效的但泄漏的数据流故意错误怎么办？

下面是一个测试程序，证明java.util.zip。*不会保留打开zip/jar文件的文件描述符，也不会检测到zip文件已更改。

import java.util.zip.*; 
import java.io.*; 

public class ZipCrashTest { 
    public static void main(String args[]) throws Exception { 
     // create some test data 
     final StringBuilder sb = new StringBuilder(); 
     for (int i = 0; i < 100000; i++) sb.append("Hello, World\n"); 
     final byte[] data = sb.toString().getBytes(); 

     // create a zip file 
     try (ZipOutputStream zo = new ZipOutputStream(new FileOutputStream("test1.zip"))) { 
      zo.putNextEntry(new ZipEntry("world.txt")); zo.write(data, 0, data.length); zo.closeEntry(); 
      zo.putNextEntry(new ZipEntry("hello.txt")); zo.write(data, 0, data.length); zo.closeEntry(); 
     } 

     // create a second valid zip file, but with different contents 
     try (ZipOutputStream zo = new ZipOutputStream(new FileOutputStream("test2.zip"))) { 
      zo.putNextEntry(new ZipEntry("hello.txt")); zo.write(data, 0, data.length); zo.closeEntry(); 
      zo.putNextEntry(new ZipEntry("world.txt")); zo.write(data, 0, data.length); zo.closeEntry(); 
     } 

     // open the zip file 
     final ZipFile zf = new ZipFile("test1.zip"); 

     // read the first file from it 
     try (InputStream is = zf.getInputStream(zf.getEntry("hello.txt"))) { 
      while (is.read() != -1) { /* do nothing with the data */ } 
     } 

     // replace the contents of test1.zip with the different-but-still-valid test2.zip 
     Runtime.getRuntime().exec("cp test2.zip test1.zip"); 

     // read another entry from test1.zip: it does not detect that the file has changed. 
     // the program will crash here 
     try (InputStream is = zf.getInputStream(zf.getEntry("world.txt"))) { 
      while (is.read() != -1) { /* do nothing */ } 
     } 
    } 
}

运行这个程序应该给你一个JVM崩溃：

# A fatal error has been detected by the Java Runtime Environment: 
# 
# SIGBUS (0x7) at pc=0x00007fb0fbbeef72, pid=4140, tid=140398238095104 
... 
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 
C [libzip.so+0x4f72] Java_java_util_zip_ZipFile_getZipMessage+0x1132 
C [libzip.so+0x5d7f] ZIP_GetEntry+0xcf 
C [libzip.so+0x3904] Java_java_util_zip_ZipFile_getEntry+0xb4 
j java.util.zip.ZipFile.getEntry(J[BZ)J+0 
j java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+38 
j ZipCrashTest.main([Ljava/lang/String;)V+476

主要缺陷提出了对JVM这是JDK-4425695 : Updating jar files crashes running programs。

RFE 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile在JDK7中实现了系统属性 - sun.zip.disableMemoryMapping - 您可以将其用作解决方法。

来源

2014-02-07 13:07:43

0

我不知道你是否已经解决了这个问题，因为我遇到了一模一样的问题。我只使用mmap将64KB文件映射到内存中，并使用memcpy将数据复制到/从缓冲区中。当我使用JNI或使用JNA时发生同样的错误。我是一位经验丰富的JNI程序员多年，我在一个纯粹的C程序中实现了相同的逻辑，其工作得很好。

我以为这是一个JDK的错误，这错误陷阱一些兴趣小组。但我真的没有时间再去挖掘它。现在我决定放弃这种做法，尝试其他方式去做我想做的事情。

如果你有兴趣，为什么我这样做，我只是想实现JNI线程安全的内存映射文件。因为在JDK的实现中，位置是ByteBuffer中的全局变量（从FileChannel映射而来）。我只想使用一个MemoryMappedBuffer实例来访问我在C++程序中完成的多个线程中的内容。

顺便说一句，我使用的是JDK 7的Mac OS X 10.10。

来源

2014-10-27 02:18:11

1

问题是zip/JAR文件在使用时被覆盖。 用于ZIP文件格式的OpenJDK代码在本地C代码中进行任何条目查找，创建需要多次昂贵的jni调用的往返。 当前的本地C实现代码使用mmap映射中央目录表，当其它ZipFile仍在使用新内容时，底层jar文件被覆盖时，vm崩溃的风险很大，这就是发生的情况。使用 - Dsun.zip.disableMemoryMapping = true将解决此问题，

JDK9早期访问版本可用，为此提供了解决方案。

检查原始发行https://bugs.openjdk.java.net/browse/JDK-8142508已被固定在9次月初访问构建97

来源

2017-04-27 12:20:31 Fairoz

相关问题

 相关问题