14

私の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
#

---------------  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
4

5 に答える 5

24

同様のエラーが発生しました。現在の疑いは、プロセスの実行中に（アップグレードプロセスによって）再書き込みされるjarファイルです。

于 2009-08-21T19:19:35.107 に答える
18

答え1は正解です。java.util.zip。*の実装に問題があります。

Javaプログラムが現在「開いている」（ZipFile / JARFileオブジェクトをキャッシュしている）zip / jarファイルを置き換えると、元のファイルから読み取ったキャッシュされた目次（TOC）データが使用され、試行されます。それを使用して、置き換えられたファイルのデータを解凍します。インフレコードは堅牢ではなく、悪いデータが提示されると完全にクラッシュします。

通常のUNIXプログラムは、ファイルを操作している間、ファイルを開いたままにします。ファイルを上書きしても、ファイルを使用しているプログラムは、開いているファイル記述子により、開いた元のファイルにアクセスできます。

OpenJDKのjava.util.zip。*実装は、zip/jarファイルのファイル記述子を開いたままにしないことを選択しました。この理由の1つは、Javaがクラスパス内の数百のjarファイルで呼び出されることが多く、設計者がjarファイルだけで数百のファイル記述子を使い果たしてプログラム自体に何も残さないようにしたかったためです。そのため、jar / zipの目次を読み取るとすぐにファイル記述子を閉じ、内容が変更された場合は元のjar/zipファイルに完全にアクセスできなくなります。

何らかの理由で、ZipFileはzip/jarファイルが変更されたことを認識しないか認識できません。もしそうなら、それが不可能な場合は、目次を読み直すか、ある種のエラーをスローする可能性があります。

さらに、目次が有効なままであっても、インフレータが誤ったデータでクラッシュするという問題があります。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です。jarファイルを更新すると、実行中のプログラムがクラッシュします。

RFE 6929479：システムプロパティsun.zip.disableMemoryMappingを追加して、ZipFileでのmmapの使用を無効にすると、JDK7にシステムプロパティが実装されます---sun.zip.disableMemoryMapping回避策として使用できます。

于 2014-02-07T13:07:43.833 に答える
3

問題は、使用中にzip/JARファイルが上書きされていることです。ZIPファイル形式のOpenJDKコードは、任意のエントリルックアップのネイティブCコードであり、作成には、高価なjni呼び出しの複数のラウンドトリップが必要です。現在のネイティブC実装コードは、mmapを使用して中央ディレクトリテーブルにマップします。これは、基になるjarファイルが他のZipFileによって使用されている間に新しいコンテンツで上書きされると、vmがクラッシュする大きなリスクです。--Dsun.zip.disableMemoryMapping = trueを使用すると、問題が解決します。

これを解決するJDK9早期アクセスビルドが利用可能です。

9早期アクセスビルド97で修正された元の問題https://bugs.openjdk.java.net/browse/JDK-8142508を確認してください。

于 2017-04-27T12:20:31.390 に答える
1

普通のol以外。JVMのバグ（最新バージョンにアップグレードして、二度と起こらないことを願っています）-またはJNIを使​​用するバグのある3.パーティライブラリ、これを引き起こす可能性のある他の2つの「興味深い」ことがあります。

  1. ハードウェア障害-RAMの不良は、ファイルシステムの破損が原因でドライブが不安定になる可能性があるため、多くの場合、適切な候補です。

  2. Solarisで実行している場合、JVMがjar / classファイルをmmapする場合に、JVMがクラス/ jarファイルにアクセスする必要があるときに、何らかの理由でクラス/ jarファイルが切り捨てられると、SIGBUSエラーが発生する可能性があります。

于 2009-08-21T18:37:14.163 に答える
0

私はまったく同じ問題に遭遇したので、あなたが問題を解決したかどうかはわかりません。私はmmapを使用して64KBファイルをメモリにマップし、memcpyを使用してデータをバッファとの間でコピーします。JNIを使​​用する場合、またはJNAを使用する場合にも、同じエラーが発生しました。私は何年も経験豊富なJNIプログラマーであり、まったく同じロジックを純粋なCプログラムに実装しています。これは非常にうまく機能します。

いくつかのSIGをトラップするのはJDKのバグだと思います。しかし、私は本当にそれをもう掘る時間がありません。今のところ、私はこのアプローチを放棄し、やりたいことをするために他の方法を試すことにしました。

私がこれを行う理由に興味がある場合は、JNIにスレッドセーフなメモリマップトファイルを実装したいと思います。JDKの実装では、位置はByteBuffer（FileChannelからマップされる）のグローバル変数であるためです。1つのMemoryMappedBufferインスタンスを使用して、C++プログラムで行った複数のスレッドのコンテンツにアクセスしたいだけです。

ところで、私はMac OSX10.10でJDK7を使用しています。

于 2014-10-27T02:18:11.370 に答える