在类加载期间，memcpy时JVM崩溃
我的JVM崩溃了，hs_err文件显示它在尝试加载类时崩溃了。 特别是在尝试memcpy时（[libc.so.6 + 0x6aa2c] memcpy + 0x1c）。 我查看了.class文件，并确定了正在加载的类。
但任何人都可以告诉我是什么原因可以导致我或者我如何能够更多地了解原因？ 如果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 # --------------- THREAD --------------- 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 --------------- PROCESS --------------- 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 我们看到过类似的错误。 我们当前的嫌疑人是jar文件，在进程运行时会重写（通过升级过程）。
答案1是正确的。 java.util.zip。*的实现有问题。
如果替换Java程序当前具有“打开”的zip / jar文件（已缓存ZipFile / JarFile对象），它将使用从原始文件读取的缓存目录（TOC）数据，并将尝试并使用它来解压缩替换文件中的数据。 通胀代码不健全，并且在出现不良数据时会彻底崩溃。
正常的unix程序在文件处理时保持文件打开状态。 如果您覆盖该文件，使用它的程序仍然可以访问它打开的原始文件，凭借打开的文件描述符。
OpenJDK的java.util.zip。*实现选择不保持zip / jar文件的文件描述符。 其中一个原因可能是Java经常在类路径中调用数百个jar文件，并且设计人员不希望仅在jar文件上使用数百个文件描述符，而没有留给程序本身。 因此，一旦他们读取了jar / zip目录，他们就会关闭文件描述符，如果内容发生变化，他们将永久失去对原始jar / zip文件的访问权限。
无论出于何种原因，ZipFile不会或不能告诉zip / jar文件已更改。 如果确实如此，它可以重新读取TOC或者如果不可能则抛出某种错误。
此外，即使TOC保持有效，但是inflater在故障数据上崩溃也是一个问题。 如果ZIP目录表有效但被泄露的数据流故意错误怎么办？
这是一个测试程序，certificatejava.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：更新jar文件会导致运行程序崩溃 。
RFE 6929479：添加系统属性sun.zip.disableMemoryMapping以禁用在ZipFile中使用mmap，在JDK7中实现系统属性 - sun.zip.disableMemoryMapping - 您可以将其用作变通方法。
问题是zip / JAR文件在使用时被覆盖。 ZIP文件格式的OpenJDK代码是在本机C代码中的任何条目查找，创建需要多次往返昂贵的jni调用。 当前的本机C实现代码使用mmap映射到中央目录表中，当底层jar文件被其他ZipFile仍在使用时，底层jar文件被新内容覆盖时，vm崩溃的风险很大，这就是正在发生的事情。 使用-Dsun.zip.disableMemoryMapping = true将解决问题，
JDK9早期访问版本可用于此解决方案。
检查已在9早期版本97中修复的原始问题https://bugs.openjdk.java.net/browse/JDK-8142508 。
除了普通的ol。 JVM中的错误（升级到最新版本并希望它不会再次发生） – 或者使用JNI的一些错误的3.方库，还有其他2个可能导致此问题的“有趣”事情。
-
硬件故障 – 糟糕的RAM通常是一个很好的选择，一个损坏的文件系统可能导致一个片状驱动器也可能是一个罪魁祸首。
-
如果您在Solaris上运行，如果在JVM需要访问它时，如果JVM mmaps jar / class文件，那么在某种情况下类/ jar文件被截断时，您可能会收到SIGBUS错误。
我不知道你是否解决了这个问题，因为我遇到了完全相同的问题。 我只使用mmap将64KB文件映射到内存中，并使用memcpy将数据复制到缓冲区或从缓冲区复制数据。 当我使用JNI或使用JNA时发生了同样的错误。 我是一名经验丰富的JNI程序员多年，我在一个纯C程序中完全实现了相同的逻辑。
我认为这是一个JDK的错误，它会捕获一些SIG。 但我真的没有时间去挖掘它了。 现在我决定放弃这种方法，并尝试其他方式做我想做的事情。
如果你对我为什么要这样做感兴趣，我只想在JNI中实现一个线程安全的内存映射文件。 因为在JDK的实现中，位置是ByteBuffer中的全局变量（从FileChannel映射）。 我只想使用一个MemoryMappedBuffer实例来访问我在C ++程序中完成的多个线程中的内容。
顺便说一下，我在Mac OS X 10.10中使用JDK 7。