आप JVM को कैसे क्रैश करते हैं?

Question

मैं प्रोग्रामिंग कौशल पर एक पुस्तक पढ़ रहा था जिसमें लेखक साक्षात्कारकर्ता से पूछता है, "आप JVM को कैसे क्रैश करते हैं?" मैंने सोचा था कि आप एक अनंत फॉर-लूप लिखकर ऐसा कर सकते हैं जो अंततः सभी मेमोरी का उपयोग करेगा।

किसी को भी कोई विचार है?

Answer 1

एक भी "जवाब" के निकटतम बात System.exit() है जो उचित सफाई के बिना तुरंत JVM को समाप्त करता है। लेकिन इसके अलावा, देशी कोड और संसाधन थकावट सबसे अधिक संभावित उत्तर हैं। वैकल्पिक रूप से आप JVM के अपने संस्करण में बग के लिए सूर्य के बग ट्रैकर को देख सकते हैं, जिनमें से कुछ दोहराने योग्य दुर्घटना परिदृश्यों की अनुमति देता है। 32-बिट संस्करणों के तहत 4 जीबी मेमोरी सीमा के करीब आने पर हम सेमी-नियमित क्रैश प्राप्त करते थे (हम आम तौर पर अब 64-बिट का उपयोग करते हैं)।

Answer 2

JNI। वास्तव में, जेएनआई के साथ, क्रैशिंग ऑपरेशन का डिफ़ॉल्ट तरीका है। क्रैश न होने के लिए आपको अतिरिक्त मेहनत करनी है।

Answer 3

दुर्घटना से आपका क्या मतलब है इस पर निर्भर करता है।

आप स्टैक स्पेस से बाहर निकलने के लिए एक अनंत रिकर्सन कर सकते हैं, लेकिन यह "कृपापूर्वक" क्रैश हो जाएगा। आपको अपवाद मिलेगा, लेकिन JVM स्वयं सबकुछ संभालेगा।

आप देशी कोड को कॉल करने के लिए जेएनआई का भी उपयोग कर सकते हैं। यदि आप इसे सही नहीं करते हैं तो आप इसे क्रैश कर सकते हैं। उन दुर्घटनाओं को डीबग करना "मजेदार" है (मेरा विश्वास करो, मुझे एक बड़ा सी ++ डीएलएल लिखना था जिसे हम एक हस्ताक्षरित जावा एप्लेट से कॉल करते हैं)। :)

Answer 4

आप एक ही कार्य करने के लिए एक पुनरावर्ती कॉल करने के लिए पाश के लिए है कि अनंत को बदलते हैं, तो आप एक ढेर अतिप्रवाह अपवाद मिलेगा:

public static void main(String[] args) { 
    causeStackOverflow(); 
} 

public void causeStackOverflow() { 
    causeStackOverflow(); 
} 

Answer 5

एक सही JVM कार्यान्वयन कभी भी क्रैश नहीं होगा।

जेएनआई से अलग एक JVM को क्रैश करने के लिए, आपको स्वयं VM में एक बग खोजने की आवश्यकता है। एक अनंत लूप बस सीपीयू का उपभोग करता है। असीमित रूप से स्मृति आवंटित करने से केवल एक अच्छी तरह से निर्मित JVM में OutOfMemoryError का कारण बनना चाहिए। यह शायद अन्य धागे के लिए समस्याएं पैदा करेगा, लेकिन एक अच्छा JVM अभी भी क्रैश नहीं होना चाहिए।

आप वी एम के स्रोत कोड में एक बग मिल सकते हैं, और उदाहरण के लिए वी एम के कार्यान्वयन की स्मृति के उपयोग में एक विभाजन गलती का कारण है, तो आप वास्तव में कुचल सकता है।

Answer 6

जॉन मेयर द्वारा Java Virtual Machine पुस्तक में बाइटकोड निर्देशों की एक श्रृंखला का एक उदाहरण है जो जेवीएम को कोर डंप का कारण बनता है। मुझे इस पुस्तक की मेरी प्रति नहीं मिल रही है। अगर किसी के पास कोई है तो कृपया इसे देखें और उत्तर पोस्ट करें।

Answer 7

मैं एक आउटऑफमेमरी एरर या स्टैक ओवरवरफ्लो को क्रैश करने के लिए कॉल नहीं कहूंगा। ये केवल सामान्य अपवाद हैं। वास्तव में वीएम को दुर्घटनाग्रस्त करने के लिए 3 तरीके हैं:

1. जेएनआई का उपयोग करें और मूल कोड में क्रैश करें।
2. यदि कोई सुरक्षा प्रबंधक स्थापित नहीं है तो आप वीएम को क्रैश करने के लिए प्रतिबिंब का उपयोग कर सकते हैं। यह वीएम सटीक है, लेकिन आम तौर पर एक वीएम निजी क्षेत्रों में देशी संसाधनों के लिए संकेत का एक समूह (जैसे देशी धागा वस्तु के लिए एक सूचक java.lang.Threadमें एक लंबे क्षेत्र में संग्रहीत किया जाता है) संग्रहीत करता है। बस उन्हें प्रतिबिंब के माध्यम से बदलें और वीएम जल्द या बाद में दुर्घटनाग्रस्त हो जाएगा।
3. सभी वीएम में बग हैं, इसलिए आपको बस एक ट्रिगर करना होगा।

पिछले विधि मैं एक छोटी उदाहरण है, जो एक सूर्य हॉटस्पॉट वीएम शांत अच्छी तरह से दुर्घटना पड़ेगा:

public class Crash { 
    public static void main(String[] args) { 
     Object[] o = null; 

     while (true) { 
      o = new Object[] {o}; 
     } 
    } 
} 

यह जीसी में एक ढेर अतिप्रवाह की ओर जाता है, ताकि आप कोई StackOverflowError मिल जाएगा लेकिन एक वास्तविक क्रैश एक hs_err * फ़ाइल सहित।

Answer 8

यदि आप एक अनचाहे स्थिति (यानी जावा अपवाद या त्रुटि) के कारण एक प्रक्रिया को रद्द करने के रूप में क्रैश को परिभाषित करते हैं, तो यह जावा के भीतर से नहीं किया जा सकता है (जब तक कि आपको sun.misc.Unsafe क्लास का उपयोग करने की अनुमति न हो)। यह प्रबंधित कोड का पूरा बिंदु है।

देशी कोड में विशिष्ट क्रैश गलत स्मृति क्षेत्रों (शून्य पता या मिसाइल हस्ताक्षर) के लिए डी-रेफरेंसिंग पॉइंटर्स द्वारा होता है। एक और स्रोत अवैध मशीन निर्देश (opcodes) या लाइब्रेरी या कर्नेल कॉल से unhandled सिग्नल हो सकता है। दोनों को ट्रिगर किया जा सकता है यदि JVM या सिस्टम लाइब्रेरी में बग हैं।

उदाहरण के लिए जेआईटीएड (जेनरेट) कोड, देशी विधियों या सिस्टम कॉल (ग्राफिक्स ड्राइवर) में वास्तविक क्रैश होने वाली समस्याएं हो सकती हैं (जब आप ज़िप फ़ंक्शंस का उपयोग करते हैं तो क्रैश होने के लिए काफी आम था और वे स्मृति से बाहर हो गए थे)। उन मामलों में जेवीएम का क्रैश हैंडलर राज्य में डंप करता है और डंप करता है। यह एक ओएस कोर फ़ाइल भी उत्पन्न कर सकता है (विंडोज़ पर डॉ वाटसन और * निक्स पर कोर डंप)।

लिनक्स/यूनिक्स पर आप आसानी से चल रहे प्रक्रिया में सिग्नल भेजकर एक JVM क्रैश कर सकते हैं। नोट: आपको इसके लिए SIGSEGV का उपयोग नहीं करना चाहिए, क्योंकि हॉटस्पॉट इस सिग्नल को पकड़ता है और इसे अधिकांश स्थानों पर एक NullPointerException के रूप में फिर से फेंकता है। तो उदाहरण के लिए SIGBUS भेजना बेहतर है।

Answer 9

winxpsp2 डब्ल्यू/WMP10 jre6.0_7

Desktop.open (uriToAviOrMpgFile) पर

यह ध्यान में न आया फेंकने योग्य फेंकने के लिए एक पैदा की धागा कारण बनता है और हॉटस्पॉट दुर्घटनाओं

YMMV

Answer 10

यहाँ

है JVM को कोर डंप (यानी क्रैश) का कारण बनने के बारे में एक विस्तृत स्पष्टीकरण: http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_17534

Answer 11

मैं इसे अभी कर रहा हूं, लेकिन पूरी तरह से यह सुनिश्चित नहीं करता कि कैसे ... :-) जेवीएम (और मेरा ऐप) कभी-कभी बस पूरी तरह से गायब हो जाता है। कोई त्रुटि नहीं फेंक दी, कुछ भी लॉग इन नहीं किया। बिना किसी चेतावनी के तुरंत चलने के लिए काम करने से जाता है।

Answer 12

आप नाटक करने के लिए आप स्मृति शेष नहीं है आप

public static void main(String[] args) { 
    throw new OutOfmemoryError(); 
} 

कर सकते हैं मैं देशी तरीकों को फोन करके एक त्रुटि फ़ाइल डंप JVM पैदा करने के लिए जिस तरह से के एक जोड़े को पता चाहते हैं (लोगों, जिसमें निर्माण कर रहे हैं) , लेकिन शायद यह सबसे अच्छा है कि आप यह नहीं जानते कि यह कैसे करें। ;)

Answer 13

जेएनआई दुर्घटनाओं का एक बड़ा स्रोत है। आप JVMTI इंटरफ़ेस का उपयोग करके भी क्रैश कर सकते हैं क्योंकि इसे सी/सी ++ में भी लिखा जाना चाहिए।

Answer 14

टूटा हुआ हार्डवेयर किसी भी प्रोग्राम को क्रैश कर सकता है। सटीक उसी सेटअप के साथ अन्य मशीनों पर ठीक चलते समय एक बार एक विशिष्ट मशीन पर एक बार ऐप क्रैश होता था। बाहर निकलता है कि मशीन में दोषपूर्ण रैम था।

Answer 15

उपयोग करें:

import sun.misc.Unsafe; 

public class Crash { 
    private static final Unsafe unsafe = Unsafe.getUnsafe(); 
    public static void crash() { 
     unsafe.putAddress(0, 0); 
    } 
    public static void main(String[] args) { 
     crash(); 
    } 
} 

, क्योंकि यह विश्वसनीय कोड उपयोग कर रहा है इस वर्ग बूट classpath पर होना चाहिए, ताकि इस तरह चलाएँ:

java -Xbootclasspath/p:. Crash

Answer 16

इस कोड को दुर्घटना होगा बुरा मायनों में JVM

import sun.dc.pr.PathDasher; 

public class Crash 
{ 
    public static void main(String[] args) 
    {  
     PathDasher dasher = new PathDasher(null) ; 
    } 
} 

Answer 17

आप JVM दुर्घटना करना चाहते हैं - का उपयोग सूर्य JDK में निम्नलिखित 1.6_23 या नीचे:

Double.parseDouble("2.2250738585072012e-308"); 

यह सूर्य जेडीके में bug के कारण है - ओपनजेडीके में भी पाया जाता है। यह ओरेकल जेडीके 1.6_24 के बाद से तय किया गया है।

Answer 18

मैं यहां आया क्योंकि मैं चाड फाउलर द्वारा The Passionate Programmer में इस प्रश्न में भी भाग गया था। जिन लोगों के पास प्रतिलिपि नहीं है, उनके लिए प्रश्न "वास्तव में अच्छे जावा प्रोग्रामर" की आवश्यकता वाले पद के लिए साक्षात्कार करने वाले उम्मीदवारों के लिए फ़िल्टर/परीक्षण के रूप में तैयार किया गया है।

विशेष रूप से, वह पूछता है:

How would you write a program, in pure Java, that would cause the Java Virtual Machine to crash?

मैं 15 साल के लिए जावा में प्रोग्राम है, और मैं इस सवाल का पाया दोनों पेचीदा और अनुचित होने के लिए। जैसा कि अन्य ने इंगित किया है, जावा, एक प्रबंधित भाषा के रूप में, विशेष रूप से को को क्रैश नहीं करने के लिए डिज़ाइन किया गया है। बेशक हमेशा JVM बग होते हैं, लेकिन:

1. उत्पादन-स्तर जेआरई के 15+ वर्षों के बाद, यह दुर्लभ है।
2. ऐसी किसी भी बग को अगली रिलीज में पैच करने की संभावना है, तो आप जेआरई शो-स्टॉपर्स के वर्तमान सेट के विवरण को चलाने और याद करने के लिए प्रोग्रामर के रूप में कितने संभावित हैं?

जैसा कि अन्य ने उल्लेख किया है, जेएनआई के माध्यम से कुछ मूल कोड जेआरई को तोड़ने का एक निश्चित तरीका है। लेकिन लेखक ने विशेष रूप से शुद्ध जावा में उल्लेख किया है, तो यह बाहर है।

एक और विकल्प जेआरई बोगस बाइट कोड को खिलाना होगा;

$ echo 'crap crap crap' > crap.class 
$ java crap 
Exception in thread "main" java.lang.ClassFormatError: Incompatible magic value 1668440432 in class file crap 

कि गिनती करता है: यह एक .class फाइल करने के लिए कुछ कचरा बाइनरी डेटा डंप करने के लिए, और JRE पूछना इसे चलाने के लिए बहुत आसान है? मेरा मतलब है कि जेआरई खुद दुर्घटनाग्रस्त नहीं हुआ है; यह ठीक से बोगस कोड का पता चला, इसकी सूचना दी, और बाहर निकला।

यह हमें सबसे स्पष्ट प्रकार के समाधानों के साथ छोड़ देता है जैसे रिकर्सन के माध्यम से ढेर उड़ाना, ऑब्जेक्ट आवंटन के माध्यम से ढेर मेमोरी से बाहर चलना, या बस RuntimeException फेंकना। लेकिन यह सिर्फ जेआरई को StackOverflowError या इसी तरह के अपवाद के साथ बाहर निकलने का कारण बनता है, जो कि फिर से वास्तव में क्रैश नहीं है।

तो क्या बचा है? मुझे वास्तव में यह सुनना अच्छा लगेगा कि लेखक को वास्तव में उचित समाधान के रूप में क्या दिमाग में था।

अद्यतन: चाड फाउलर responded here।

पुनश्च: यह एक अन्यथा महान पुस्तक है। रुबी सीखते समय मैंने इसे नैतिक समर्थन के लिए उठाया।

Answer 19

कम से कम जिस तरह से :)

public class Crash 
{ 
    public static void main(String[] args) 
    { 
     main(args); 
    } 
} 

Answer 20

पिछली बार मैंने यह करना होगा करने की कोशिश की:

public class Recur { 
    public static void main(String[] argv) { 
     try { 
      recur(); 
     } 
     catch (Error e) { 
      System.out.println(e.toString()); 
     } 
     System.out.println("Ended normally"); 
    } 
    static void recur() { 
     Object[] o = null; 
     try { 
      while(true) { 
       Object[] newO = new Object[1]; 
       newO[0] = o; 
       o = newO; 
      } 
     } 
     finally { 
      recur(); 
     } 
    } 
} 

उत्पन्न लॉग फ़ाइल का पहला भाग:

# 
# An unexpected error has been detected by Java Runtime Environment: 
# 
# EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x000000006dad5c3d, pid=6752, tid=1996 
# 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode windows-amd64) 
# Problematic frame: 
# V [jvm.dll+0x2e5c3d] 
# 
# 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 (0x00000000014c6000): VMThread [stack: 0x0000000049810000,0x0000000049910000] [id=1996] 

siginfo: ExceptionCode=0xc00000fd, ExceptionInformation=0x0000000000000001 0x0000000049813fe8 

Registers: 
EAX=0x000000006dc83090, EBX=0x000000003680f400, ECX=0x0000000005d40ce8, EDX=0x000000003680f400 
ESP=0x0000000049813ff0, EBP=0x00000000013f2df0, ESI=0x00000000013f0e40, EDI=0x000000003680f400 
EIP=0x000000006dad5c3d, EFLAGS=0x0000000000010206 

Answer 21

तो एक 'क्रैश 'ऐसा कुछ भी है जो जेवीएम/प्रोग्राम को सामान्य समाप्ति से बाधित करता है, फिर एक अन-हैंडल अपवाद यह कर सकता है।

public static void main(String args[]){ 
    int i = 1/0; 
    System.out.print(i); // This part will not be executed due to above unhandled exception 
    } 

तो, यह किस प्रकार का CRASH पर निर्भर करता है?

Answer 22

नहीं

एक दुर्घटना है, लेकिन

Runtime.getRuntime().halt(status)

बुला डॉक्स के अनुसार द्वारा System.exit

का उपयोग कर आप JVM को रोक सकते हैं के स्वीकार किए जाते हैं जवाब की तुलना में एक दुर्घटना के करीब: -

"this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled".

Answer 23

सबसे छोटा? CTRL + BREAK को ट्रिगर करने के लिए रोबोट क्लास का उपयोग करें। मैंने इसे देखा जब मैं कंसोल बंद किए बिना अपना प्रोग्राम बंद करने की कोशिश कर रहा था (इसमें कोई 'बाहर निकलने' कार्यक्षमता नहीं थी)।

Answer 24

आप एक धागा प्रक्रिया है कि असीम अधिक धागे आपको धीरे-धीरे JVM अपने आप में एक ढेर अतिप्रवाह त्रुटि का कारण होगा (जो अधिक धागे, जो ... अंडे) spawns बनाते हैं।

public class Crash { 
    public static void main(String[] args) { 

     Runnable[] arr = new Runnable[1]; 
     arr[0] =() -> { 

      while (true) { 
       new Thread(arr[0]).start(); 
      } 
     }; 

     arr[0].run(); 
    } 
} 

यह मैं उत्पादन दे दी है (5 मिनट के बाद, अपने राम घड़ी)

An unrecoverable stack overflow has occurred. 
# 
# A fatal error has been detected by the Java Runtime Environment: 
# 
# EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x0000000070e53ed7, pid=12840, tid=0x0000000000101078 
# 
# JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01) 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode windows-amd64 compressed oops) 
# Problematic frame: 
#