कक्षा लोड

Question

के दौरान 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 
# 

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

Answer 1

हमने इसी तरह की त्रुटियां देखी हैं। हमारी वर्तमान संदिग्ध जार फाइलें हैं जो प्रक्रिया चल रही हैं, फिर से लिखे गए हैं (एक अपग्रेड प्रक्रिया द्वारा)।

Answer 2

एक सादे ओल के अलावा। JVM में बग (नवीनतम संस्करण में अपग्रेड करें और उम्मीद है कि यह फिर से नहीं होगा) - या कुछ छोटी गाड़ी 3. जेएनआई का उपयोग कर पार्टी लाइब्रेरी, 2 अन्य "रोचक" चीजें हैं जो इसका कारण बन सकती हैं।

1. हार्डवेयर विफलता - बुरा रैम एक अच्छे उम्मीदवार ओ.टी. एक दूषित फाइल सिस्टम एक परतदार ड्राइव का कारण बन सकता है एक अपराधी भी हो सकता है अक्सर है।

2. यदि आप सोलारिस पर चल रहे हैं, तो आप सिगबस त्रुटियों को प्राप्त कर सकते हैं यदि किसी भी तरह से क्लास/जार फ़ाइल को तब छोटा कर दिया गया जब JVM को जेवीएम को जार/क्लास फ़ाइल को मैप करने के मामले में इसे एक्सेस करने की आवश्यकता होती है।

Answer 3

उत्तर 1 सही है। Java.util.zip का कार्यान्वयन * गलती पर है।

आप एक ज़िप/जार फ़ाइल है कि एक जावा प्रोग्राम वर्तमान में "खुले" (zipfile/JarFile वस्तु कैश की गई है) है की जगह है, यह कैश की गई तालिका के- सामग्री (टीओसी) डेटा यह मूल फ़ाइल से पढ़ने का उपयोग करेगा , और प्रतिस्थापित फ़ाइल में डेटा अनपैक करने के लिए कोशिश करेगा और इसका उपयोग करेगा। मुद्रास्फीति कोड मजबूत नहीं है और खराब डेटा के साथ प्रस्तुत होने पर पूरी तरह दुर्घटनाग्रस्त हो जाएगा।

सामान्य यूनिक्स प्रोग्राम फ़ाइलें उनके साथ काम करते समय खुले रहते हैं। यदि आप फ़ाइल को ओवरराइट करते हैं, तो इसका उपयोग करने वाले प्रोग्राम में अभी भी खुली फ़ाइल डिस्क्रिप्टर के आधार पर खोले गए मूल तक पहुंच है।

ओपनजेडीके का java.util.zip। * कार्यान्वयन ने फ़ाइल डिस्क्रिप्टर को ज़िप/जार फ़ाइलों के लिए खोलने के लिए नहीं चुना है। इसका एक कारण यह हो सकता है कि जावा को कक्षा पथ में सैकड़ों जार फ़ाइलों के साथ अक्सर बुलाया जाता है, और डिजाइनर अकेले जार फ़ाइलों पर सैकड़ों फ़ाइल डिस्क्रिप्टर का उपयोग नहीं करना चाहते थे, जिससे प्रोग्राम के लिए कोई भी नहीं छोड़ा गया था। इसलिए जब वे सामग्री की जार/ज़िप तालिका पढ़ते हैं, तो वे फ़ाइल डिस्क्रिप्टर को बंद करते हैं, और मूल जार/ज़िप फ़ाइल तक पहुंच को स्थायी रूप से खो देते हैं, इसकी सामग्री बदलनी चाहिए।

किसी भी कारण से, ज़िपफाइल ज़िप/जार फ़ाइल को नहीं बताता या नहीं बता सकता है। यदि ऐसा होता है, तो यह टीओसी को फिर से पढ़ सकता है या अगर यह संभव नहीं है तो किसी प्रकार की त्रुटि फेंक सकता है।

इसके अलावा, भले ही टीओसी वैध रहे, फिर भी यह एक समस्या है कि inflator दोषपूर्ण डेटा पर दुर्घटनाग्रस्त हो जाता है। क्या होगा यदि ज़िप तालिका-सामग्री मान्य थी लेकिन डिफलेटेड डेटा स्ट्रीम जानबूझकर गलत थी?

यहां एक परीक्षण कार्यक्रम है जो java.util.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 जेडीके 7 - sun.zip.disableMemoryMapping में एक सिस्टम प्रॉपर्टी लागू करता है - जिसे आप वर्कअराउंड के रूप में उपयोग कर सकते हैं।

Answer 4

मुझे नहीं पता कि आपने समस्या हल कर दी है क्योंकि मुझे बिल्कुल वही समस्या आई है। मैं केवल 64 केबी फ़ाइल को स्मृति में मैप करने के लिए एमएमएपी का उपयोग करता हूं और बफर से डेटा कॉपी करने के लिए memcpy का उपयोग करता हूं। जब मैं जेएनआई का उपयोग करता हूं या जब मैं जेएनए का उपयोग करता हूं तो वही त्रुटि हुई। मैं वर्षों से एक अनुभवी जेएनआई प्रोग्रामर हूं और मैं बिल्कुल एक शुद्ध सी प्रोग्राम में एक ही तर्क लागू कर रहा हूं जो बहुत अच्छी तरह से काम करता है।

मुझे लगता है कि यह एक जेडीके की बग है जो कुछ एसआईजी को फंसता है। लेकिन मेरे पास वास्तव में इसे खोदने का समय नहीं है। अभी के लिए मैंने इस दृष्टिकोण को त्यागने का फैसला किया और कुछ ऐसा करने का प्रयास किया जो मैं करना चाहता हूं।

यदि आप रुचि रखते हैं कि मैं ऐसा क्यों कर रहा हूं, तो मैं जेएनआई में थ्रेड सुरक्षित मेमोरी मैप की गई फ़ाइल को लागू करना चाहता हूं। चूंकि जेडीके के कार्यान्वयन में, स्थिति बाइटबफर में एक वैश्विक चर है (जिसे फाइलचैनल से मैप किया गया है)। मैं एक सी ++ प्रोग्राम में किए गए कई थ्रेड में सामग्री तक पहुंचने के लिए बस एक मेमोरी मैप किए गए बफर उदाहरण का उपयोग करना चाहता हूं।

बीटीडब्ल्यू, मै मैक ओएस एक्स 10.10 में जेडीके 7 का उपयोग कर रहा हूं।

Answer 5

समस्या के दौरान ज़िप/जेएआर फ़ाइल ओवरराइट की जा रही है। ज़िप फ़ाइल प्रारूप के लिए ओपनजेडीके कोड देशी सी कोड में कोई एंट्री लुकअप है, निर्माण को महंगी जेनी इनवोकेशन की कई राउंड-ट्रिप की आवश्यकता है। वर्तमान देशी सी कार्यान्वयन कोड केंद्रीय निर्देशिका तालिका में मानचित्र करने के लिए एमएमएपी का उपयोग करता है जो कि वीएम दुर्घटना का एक बड़ा जोखिम है जब अंतर्निहित जार फ़ाइल नई सामग्री के साथ ओवरराइट हो जाती है, जबकि यह अभी भी अन्य ज़िपफाइल द्वारा उपयोग की जा रही है, यही हो रहा है। उपयोग - Dsun.zip.disableMemoryMapping = सत्य समस्या को हल करेगा,

जेडीके 9 प्रारंभिक पहुंच निर्माण उपलब्ध हैं जिनके लिए इसका समाधान है।

चेक मूल मुद्दा https://bugs.openjdk.java.net/browse/JDK-8142508 कि 9 शुरुआती एक्सेस निर्माण में निर्धारित किया गया है 97.