सी क्रैश कितनी बुरी तरह से हो सकता है?

Question

मैंने अक्सर सुना है कि सी शानदार रूप से क्रैश कर सकता है। हाल ही में मुझे इसका पहला स्वाद मिला जब एक फंक्शन को एक स्ट्रिंग लौटने की उम्मीद थी, इसके बदले थोड़ा खुश चेहरे लौटे। तब से मैं पॉइंटर्स शुरू करने और सरणी के लिए स्मृति को याद रखने के साथ और अधिक सावधान रहा हूं। फिर भी, मुझे विश्वास है कि एक प्रोग्राम उस बुरी तरह दुर्घटनाग्रस्त हो सकता है ...

मुझे लगता है कि यह कार्यक्रम के दायरे पर निर्भर करेगा? मेरा मतलब है, अगर आपके प्रशंसक के साथ निपटाए गए किसी कार्यक्रम में एक बग स्मृति में कुछ महत्वपूर्ण जगहों में खुश चेहरे की प्रतिलिपि बनाता है ...?

मेरा सवाल है, शानदार सी दुर्घटनाओं की दुनिया में कितनी मिथक है? क्या मुझे खतरनाक चीजों के कुछ ठोस उदाहरण मिल सकते हैं जिन्हें किसी से बचना चाहिए?

z।

Answer 1

ऑपरेटिंग सिस्टम इन दिनों सबसे भयानक मुद्दों को रोकता है। मैंने जो भी सबसे खराब किया है वह मशीन को हार्ड-लॉक करना है (केवल पावर बटन दबाकर रीबूट करना था) और कुछ फाइलों को धक्का देना था।

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

हालांकि अधिकांश भाग के लिए प्रयोग करना और खेलना ठीक है। इन दिनों सिस्टम पर्याप्त लचीले हैं कि आप एक गड़बड़ी नहीं करेंगे जो वापस पाने के लिए बहुत मुश्किल है। ऑपरेटिंग सिस्टम प्रत्येक प्रोग्राम को स्मृति के अपने टुकड़े में रखता है, और जब तक आप व्यवस्थापक/रूट नहीं होते हैं तब तक महत्वपूर्ण सिस्टम को बदलने के लिए पहुंच को अस्वीकार कर देते हैं। आपके बगीचे की विविधता वाले पॉइंटर मजाकिया चीजें मुद्रित कर सकते हैं या आपके प्रोग्राम को क्रैश कर सकते हैं, लेकिन यह एक आधुनिक कंप्यूटर को नष्ट नहीं करेगा।

एक और जवाब में एक टिप्पणी से: "मैं Nintendo DS उपयोग कर रहा हूँ उन्हें चलाने के लिए"

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

Answer 2

मुझे लगता है कि यह शायद बदतर तरीका पूर्व आभासी स्मृति दिनों में वापस था आप अन्य प्रक्रियाओं स्मृति कचरा सकता है जब, लेकिन आजकल सबसे खराब है कि हो सकता है वास्तव में सिर्फ अपने खुद के कार्यक्रम क्रैश हो रहा है। आमतौर पर खराब पॉइंटर्स से सेगमेंटेशन दोषों के माध्यम से।

जो सिस्टम संसाधनों का दुरुपयोग करके चीजों को उड़ाने के पाठ्यक्रम को छोड़ देता है - आप इसे किसी भी भाषा में कर सकते हैं।

Answer 3

सबसे बुरी बात यह है कि मुझे क्या हुआ स्मृति भ्रष्टाचार जो एक दुर्घटना के तुरंत कारण नहीं थे, लेकिन कुछ समय के बाद .. यह इतना पता लगाने के लिए मुश्किल

Answer 4

ठीक है, अगर आप लिख रहे हैं कर्नेल कोड बनाने .. अरे , कभी-कभी आप स्मृति की सिस्टम महत्वपूर्ण बिट्स को ओवरराइट कर सकते हैं, जैसे इंटरप्ट वैक्टर, ग्लोबल डिस्क्रिप्टर टेबल, प्रोसेस टेबल, मजेदार सामान के सभी प्रकार के कारण!

Answer 5

• http://xkcd.com/371/
• http://blog.raamdev.com/category/technology/programming/cc
• http://en.wikipedia.org/wiki/Segmentation_fault

Answer 6

यदि आपका कोड एक दूर से आधुनिक ओएस पर चल रहा है, तो आप स्मृति में यादृच्छिक अंक में प्रसन्न चेहरों कॉपी नहीं कर सकते। आप जितना चाहें उतना क्रैश कर सकते हैं, और इसके परिणामस्वरूप आपकी प्रक्रिया समाप्त हो जाएगी।

निकटतम आप वास्तव में अपने सिस्टम को गड़बड़ कर सकते हैं, प्रोसेसर/मेमोरी/डिस्क संसाधनों का दुरुपयोग कर रहे हैं, या इतने सारे उपप्रोसेसेस को उजागर कर रहे हैं कि ओएस पीआईडी ​​से बाहर हो जाता है (यदि यह अभी भी उनको स्टोर करने के लिए 32-बिट मान का उपयोग कर रहा है) ।

Answer 7

आजकल कड़ी मेहनत कर रहा है सी क्रैश कि हार्ड (जब तक आप ओएस कर्नेल या ऐसा कुछ कोडिंग नहीं कर रहे हों)।

DOS/Win95/Win98 दिनों में वापस, आप एक सी कार्यक्रम chash वास्तव में बहुत बुरी तरह से बना सकते हैं,। मुझे यह बहुत कुछ मिल रहा था:

जब भी मुझे एक खतरनाक सूचक ऑपरेशन था जो स्मृति के साथ गड़बड़ कर रहा था, तो मुझे अलग-अलग रंगों में, चरित्रों के सभी प्रकारों से भरा एक चरित्र आधारित स्क्रीन मिली, उनमें से कुछ चमकते हुए !!! मुझे लगता है कि ऑपरेशन वीडियो मेमोरी के साथ किसी भी तरह से गड़बड़ कर दिया।

लेकिन आज, क्योंकि प्रक्रिया सुरक्षित कर्नेल के भीतर चलती है, तो आपकी प्रक्रिया समाप्त होने पर आपको सबसे बुरा लगेगा।

Answer 8

सी स्वयं कुछ भी क्रैश नहीं कर सकता है। मैला प्रोग्रामिंग सब कुछ दुर्घटनाग्रस्त हो सकता है।

"खुश चेहरे" एक संकेत है कि आपके कोड ने स्मृति को दूषित कर दिया है। सी को केवल एक चीज करना था, यह तथ्य है कि आपने इसका इस्तेमाल करना चुना है। (और तथ्य यह है कि आपके ओएस को यह होने की इजाजत है - क्या आप अभी भी डॉस का संस्करण चला रहे हैं?)

Answer 9

जब मैं सी ++ प्रोग्राम करना सीख रहा था, तो यह मैक चल रहा सिस्टम 7 या 8 पर था याद है जो वैसे भी, इसमें कोई वर्चुअल मेमोरी मेमोरी नहीं थी, इसलिए एक लटकती पॉइंटर या बफर ओवररन छोड़ने जैसी कई गलतियों से पूरे कंप्यूटर को क्रैश हो जाएगा। मुझे याद है कि जब एप्पल पहले घोषणा की कि वे एक नया ओएस जो Macworld या कुछ और पर स्मृति स्थान की रक्षा की थी बनाने के लिए जा रहे थे, वे एक कार्यक्रम के लिए स्रोत कोड से पता चला है:

while (true) 
    *(int *)i++ = 1; 

और जब वे कार्यक्रम चलाया, लेकिन कार्यक्रम समाप्त हो गया, न कि पूरी मशीन (इसमें एक संदेश था जैसे "आपको अपने कंप्यूटर को पुनरारंभ करने की आवश्यकता नहीं है") डेवलपर्स से भरा पूरा कमरा प्रशंसा में फंस गया है। वैसे भी, स्पष्ट रूप से संरक्षित स्मृति नहीं होने से वास्तव में प्रोग्रामिंग सी या सी ++ दुर्घटना की बढ़ती गंभीरता के कारण वास्तव में कठिन बना दिया गया है।

आजकल यह इतना बड़ा सौदा नहीं है जब तक कि आप पर्यवेक्षक स्तर पर कुछ प्रोग्रामिंग नहीं कर रहे हैं, आपके पास ओएस को क्रैश करने की क्षमता नहीं है।

Answer 10

एक कंप्यूटर था, कमोडोर पीईटी 4032 (उर्फ "फैट 40") जहां वास्तव में वीडियो चिप को स्थायी रूप से जला देना संभव था यदि आपने स्मृति के गलत हिस्से में गलत मूल्य डाला। आप कल्पना कर सकते हैं कि अगर उस मशीन पर सी कंपाइलर था, तो एक जंगली सूचक वास्तव में कंप्यूटर को अपरिवर्तनीय शारीरिक क्षति कर सकता था।

Answer 11

यहाँ हेनरी स्पेंसर की 'दस आज्ञाओं सी प्रोग्रामर के लिए "से एक त्वरित टुकड़ा है:

• धर्मादेश # 2 - तू, शून्य सूचक का पालन नहीं करोगे अराजकता और पागलपन के लिए अपने अंत में तुमको इंतजार है।
• जाहिर पवित्र ग्रंथों, गलत लिखित यहाँ थे के रूप में शब्दों अशक्त संकेत की अवधारणा और स्थूल शून्य बीच भ्रम की स्थिति को कम करने के `` नल पॉइंटर '' किया जाना चाहिए था, (जो और अधिक anon की)। अन्यथा, अर्थ सादा है। ड्रेगन, राक्षसों, कोर डंप, और अगणित अन्य बेईमानी से प्राणियों, जो सभी के तेरा कार्यक्रम में frolicing में प्रसन्न से भरा क्षेत्रों के लिए एक नल पॉइंटर अंक तू उनकी नींद परेशान करता है, तो। एक निंदा सूचक किसी भी प्रकार के 0 को इंगित नहीं करता है, कुछ निंदाजनक पुराने कोड के बावजूद जो इसे समझता है।

जो लोग सी से परिचित नहीं हैं के लिए, मैं सेल्सियस के लिए सबसे अच्छा लिखा संक्षिप्त परिचय हेनरी स्पेंसर द्वारा "The Ten Commandments for C Programmers (Annotated Edition)" द्वारा किया जाता है लगता है। जिस तरह से लिखा गया है वह वास्तव में पाठक को सी के खतरों में आता है ... जबकि एक ही समय में मजाकिया हो रहा है (जिसका अर्थ है कि पाठक वास्तव में अधिक ध्यान देगा)।

=========================

निजी तौर पर

... सी कि बुरी तरह से जब आप डेस्कटॉप कर रहे हैं क्रैश नहीं होता विकास क्योंकि आपके पास seg-faulting की लक्जरी है। जब ओएस देखता है आप के लिए वास्तव में एफ 'चीजों को कोशिश कर SEG-दोष होते हैं और यह कहते हैं, "अरे! तुम वहाँ की अनुमति नहीं है" और इस प्रक्रिया रुक जाती है।

जब आप एम्बेडेड सी विकास कर रहे हैं ... वह तब होता है जब आपको वास्तव में शानदार पागल सामान मिलते हैं ... यानी वे आपको 99.9% बिजली चक्र की आवश्यकता होती है। इस एक बार जहां कोड किसी भी तरह मेरी कॉल स्टैक को खराब करता ... और फिर आप कुछ यादृच्छिक अन्य फ़ंक्शन को निष्पादित कर रहे हैं ... और जैसा तो ISR किसी भी तरह अभी भी जा रहा है ... और यह 2 सप्ताह लग जाते हैं उस तरह ओ ठीक करने के लिए बग। खोजने के लिए "ओएस नहीं मिला" या जो कुछ भी संदेश था रिबूट करने जैसा कुछ भी नहीं -

Answer 12

खैर, डॉस दिनों में वापस, मैं बूट क्षेत्र की ओवर-राइट भाग में कामयाब रहे।

आप मुश्किल तरीके से डिस्क के लिए बहुत, बहुत सावधान लेखन होने के लिए उस के बाद वापस डॉस दिनों मैं वास्तव में bios जानकारी पर लिखा में जानने ...

Answer 13

। इसे ठीक करने के लिए एक तकनीक प्राप्त करना पड़ा। मेरा पहला घर कंप्यूटर - 286. एक या दो दिन के बाद बूट करने योग्य।

Answer 14

सी आप मशीन से निपटने के बहुत सीधे के पास की सुविधा देता है। यह कितना शानदार रूप से दुर्घटनाग्रस्त हो सकता है यह एक मशीन है जो मशीन कर सकता है।

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

वहाँ हर जगह सॉफ्टवेयर है इन दिनों। इसके बारे में एक बहुत सी में लिखा है

Answer 15

वापस जब मैं Win98 ड्राइवरों लिख रहा था, बीएसओडी हर किसी अड्डा।मुझे याद है निम्नलिखित गलती मैं

typedef struct _SOME_TAG_ बनाया {

int nSomeVar; 
    int nSomeMore; 
    ... 

} MYSTRUCT, * PMYSTRUCT;

.... PMYSTRUCT pMyStruct;

// और मैं इस संरचना का उपयोग किसी भी स्मृति आवंटित किए बिना करता हूं ;-) pMyStruct-> nSomeVar = 0;

और चालक दुर्घटनाओं इतना भयानक थे, लेकिन हम Numega से एक SoftICE था, हालांकि यह केवल 10 साल पहले है .. मैं अपनी तरह उम्र वापस

Answer 16

संरक्षित स्मृति के साथ किसी भी ओएस पर लग रहा है सबसे खराब है कि हो सकता है है कि आपकी प्रक्रिया दुर्घटनाग्रस्त हो जाती है। अब अगर आपकी प्रक्रिया कर्नेल या कर्नेल एक्सटेंशन का हिस्सा बनती है तो आप स्पष्ट रूप से पूरे ओएस को क्रैश कर सकते हैं लेकिन यह सबसे खराब है जो आप कर सकते हैं।

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

तो, मैं संरक्षित स्मृति का मानना ​​है कि, सी किसी अन्य भाषा के अलावा कोई और अधिक नुकसान कर सकता है नहीं (जब तक अपनी प्रक्रिया ओएस का हिस्सा है;)

Answer 17

संरक्षित स्मृति से पहले आर्किटेक्चर,) के सबसे कूद ऑपरेटिंग सिस्टम द्वारा प्रयुक्त वैक्टर (शून्य से शुरू पते) स्मृति के शून्य पेज में संग्रहीत किया गया

तो शून्य पेज में स्मृति स्थल के लिए लिख - आसानी से अशक्त/बुरा संकेत के साथ किया - ऑपरेटिंग सिस्टम के कूद वैक्टर बदल जाएगा , विचित्र दुर्घटना व्यवहार के सभी प्रकार के कारण - बंद कर दिया-आउट कीबोर्ड से सब कुछ और वीडियो हार्ड ड्राइव प्रकाश चमकती उन्माद, मौत के नीले परदे, करने के लिए कचरा से भरा स्क्रीन निमिष रिबूट, आदि

[विधानसभा भाषा में कोडिंग और भी मजेदार था]

Answer 18

कॉलेज में वापस मैं एक बहु सूत्रण प्रॉक्सी बनाने पर काम सौंपा गया था।

समय-समय पर, प्रॉक्सी संसाधन पृष्ठ खींचा के किसी भी जवाब नहीं था। कोड के कारण समस्या:

अतिप्रवाह मुद्दों, जो किसी फ़ाइल हैंडलर के पास चर उपयोग किए जाने वाले कुछ कोड। क्या हो रहा था यह जानने से पहले, मुझे यह वास्तव में अजीब लगता है कि फ़ाइल हैंडलर घोषणा को "निश्चित" मुद्दा, lol को ले जाना।

Ps। इसे जांचें (सी में नहीं, लेकिन एक अच्छी कहानी :)): http://trixter.wordpress.com/2006/02/02/computing-myth-1-software-cannot-damage-hardware/

Answer 19

यदि पीसी में सवाल वाला सॉफ्टवेयर चल रहा है, तो यह आपके कंप्यूटर को "केवल" ला सकता है। नहीं सबसे खराब यह सिर्फ सॉफ्टवेयर है कि दुर्घटनाओं नहीं होगा ...

Answer 20

कोई क्रैश है -

अगर, हालांकि, यह इंजन के संचालन के लिए अपनी कार में नियंत्रित है - या बुरा, एबीएस चीज जो हो सकती है।

मैं एक पुराने यूनिक्स फ़ाइल संपीड़न प्रोग्राम (आप जानते हैं, पिन की तरह) कि fclose से वापसी मान जांच नहीं के बारे में पढ़ा। हां, fclose एक त्रुटि वापस कर सकते हैं। फ़ाइल में आउटपुट सामान्य रूप से buffered होता है, इसलिए यदि fwrite या putc पर कॉल करने के लिए कोई कॉल काम करता है, और ठीक है, तो डेटा अभी भी बफर में हो सकता है, लिखित होने का इंतजार कर रहा है।जब फ्लेक्स कहा जाता है, तो कोई भी अनचाहे डेटा फ़्लश हो जाता है, और यह असफल हो सकता है, क्योंकि (उदाहरण के लिए) डिस्क भर सकती है। और चूंकि संपीड़न कार्यक्रम आमतौर पर चलाता था क्योंकि डिस्क लगभग पूरी थी, यह अक्सर होता है। इसलिए कार्यक्रम ने चुपचाप नई, संपीड़ित फ़ाइल को छोटा कर दिया, मूल असम्पीडित फ़ाइल हटा दी गई, और अगले वर्ष अगले वर्ष या जब किसी ने फ़ाइल को असम्पीडित करने का प्रयास किया, तो अंत गायब था!

मुझे लगता है कि यह एक अच्छा उदाहरण है कि क्यों अपवाद फेंकना अच्छी बात हो सकती है।