सॉफ्टवेयर बग

प्रभाव

बग, टाइप I और टाइप II त्रुटियों को सक्रिय कर देते हैं जो बदले में व्यापक प्रकार के तरंगित प्रभाव पैदा कर सकते हैं जिसके कारण प्रोग्राम के उपयोगकर्ता को विविध स्तरों की असुविधाओं का सामना करना पड़ सकता है। कुछ बग प्रोग्राम की कार्यक्षमता पर सिर्फ एक हल्का सा प्रभाव डालते हैं और इस तरह एक लंबे समय तक उनका पता ही नहीं चल पाता है। अधिक गंभीर बग प्रोग्राम को क्रैश (नष्ट) या फ्रीज (निष्क्रिय) कर सकते हैं जिसकी वजह से इसकी सेवा बंद हो सकती है। अन्य बग सुरक्षा बग के रूप में समझे जाते हैं, उदाहरण के लिए, ये अनधिकृत विशेषाधिकार प्राप्त करने के क्रम में एक दुर्भावनापूर्ण उपयोगकर्ता को पहुंच संबंधी नियंत्रण का उपयोग करने में सक्षम बना सकते हैं।
बग के परिणाम अत्यंत गंभीर हो सकते हैं। 1980 के दशक में थिरेक-25 विकिरण चिकित्सा मशीन को नियंत्रित करने वाले कोड में मौजूद बग कई मरीजों की मौत के लिए सीधे तौर पर जिम्मेदार थे। 1996 में यूरोपीय अंतरिक्ष एजेंसी का 1 बिलियन अमेरिकी डॉलर का प्रोटोटाइप एरियन-5 रॉकेट ऑन-बोर्ड गाइडेंस कंप्यूटर प्रोग्राम में बग की मौजूदगी के कारण लॉन्च होने के एक मिनट से भी कम समय में नष्ट हो गया था। जून 1994 में एक रॉयल एयर फोर्स चिनूक, मल ऑफ किनटायर में दुर्घटनाग्रस्त हो गया था जिसमें 29 लोग मारे गए थे। शुरुआत में इसे एक पायलट की गलती कहकर खारिज कर दिया गया था लेकिन कंप्यूटर वीकली द्वारा की गयी एक जांच ने पर्याप्त सबूतों का खुलासा किया जो हाउस ऑफ लॉर्ड्स की एक जांच को यह विश्वास दिलाने में कामयाब रहा कि ऐसा विमान के इंजन को नियंत्रित करने वाले कंप्यूटर में मौजूद एक सॉफ्टवेयर बग के कारण हुआ हो सकता है।
2002 में अमेरिकी वाणिज्य विभाग के नेशनल इंस्टिट्यूट ऑफ स्टैंडर्ड्स एंड टेक्नोलॉजी द्वारा कराये गए एक अध्ययन ने यह निष्कर्ष दिया कि सॉफ्टवेयर बग या एरर इतने व्यापक और हानिकारक हैं कि ये अमेरिकी अर्थव्यवस्था को एक अनुमान के मुताबिक़ सालाना 59 बिलियन डॉलर या सकल घरेलू उत्पाद के लगभग 0.6 प्रतिशत का नुकसान पहुंचाते हैं।

डीबगिंग

बग का पता लगाना और उसे हटाना या "डीबगिंग" अक्सर कंप्यूटर प्रोग्रामिंग का एक महत्वपूर्ण भाग होता है।
एक प्रारंभिक कंप्यूटर विशेषज्ञ, मौरिस विल्केस ने 1940 के दशक में अपनी एक अनुभूति में उल्लेख किया था कि उनकी जिन्दगी का अधिकांश शेष भाग अपने स्वयं के प्रोग्रामों की गलतियों का पता लगाने में बीत जाएगा. जैसे-जैसे कंप्यूटर प्रोग्राम और अधिक जटिल होते जाते हैं, बग और अधिक सामान्य एवं मुश्किल से दूर किये जाने वाले हो जाते हैं। अक्सर प्रोग्रामर नए कोड लिखने की तुलना में बगों का पता लगाने और उन्हें दूर करने में ज्यादा समय लगाते हैं और कहीं अधिक प्रयास करते हैं। सॉफ्टवेयर परीक्षक ऐसे पेशेवर व्यक्ति होते हैं जिनका प्रमुख कार्य बगों का पता लगाना या परीक्षण में सहयोग करने वाले कोड लिखना होता है। कुछ प्रोजेक्टों में प्रोग्राम विकसित करने की तुलना में ज्यादा संसाधन परीक्षण में खर्च किये जा सकते हैं।
आम तौर पर डिबगिंग का सबसे अधिक मुश्किल भाग स्रोत कोड में बग का पता लगाना है। एक बार जब इसका पता लग जाता है तो इसे ठीक करना आम तौर पर अपेक्षाकृत आसान होता है। डीबगर के रूप में जाने जाने वाले प्रोग्राम भी मौजूद हैं जो एक-एक लाइन कर कोड को कार्यान्वित करने, परिवर्ती मानों पर नजर रखने और प्रोग्राम के आचरण को समझने वाली अन्य सुविधाओं के जरिये बग का पता लगाने में प्रोग्रामरों की मदद करते हैं। एक डिबगर के बिना प्रोग्राम के कार्यान्वयन का पता लगाने या मानों को दिखाने के लिए कोड को इस तरह जोड़ा जा सकता है कि संदेशों या मानों को एक कंसोल में (उदाहरण के लिए सी (C) प्रोग्रामिंग की भाषा में printf) के साथ) या एक विंडो में या लॉग फ़ाइल में लिखा जा सके।
हालांकि, एक डीबगर की सहायता से भी बग का पता लगाना कुछ हद तक एक कला है। किसी प्रोग्राम के एक सेक्शन में मौजूद किसी बग के लिए एक पूरी तरह से दूसरे सेक्शन में विफलता का कारण बनना असामान्य नहीं है जिसके कारण सिस्टम के एक स्पष्टतः असंबद्ध भाग में इसका पता लगाना (उदाहरण के लिए, एक ग्राफिक्स रेंडरिंग की दिनचर्या में किसी त्रुटि के कारण एक फ़ाइल आई/ओ संबंधी दिनचर्या का असफल हो जाना) विशेष रूप से मुश्किल हो जाता है।
कभी-कभी बग एक अलग दोष नहीं होता है बल्कि यह प्रोग्रामर की ओर से सोच या योजना की एक त्रुटि का प्रतिनिधित्व करता है। इस तरह की तार्किक त्रुटियों के लिए प्रोग्राम के उस भाग की संपूर्ण मरम्मत या उसके दुबारा लेखन की आवश्यकता होती है। कोड समीक्षा के हिस्से के रूप में, अगर ऐसा दिखाया जा सके कि इसके कार्यान्वयन में कुछ त्रुटिपूर्ण तर्क मौजूद हैं, एक विशेष प्रकार के कोड का इस्तेमाल करके ऐसे किसी बग को दुबारा उत्पन्न किये बिना ही अक्सर इन त्रुटियों का पता लगाया जा सकता है।
लेकिन कहीं अधिक विशेष रूप से किसी बग का पता लगाने में पहला चरण है इसे विश्वसनीय तरीके से पुनः प्रस्तुत करना। एक बार जब बग को पुनः प्रस्तुत कर दिया जाता है, प्रोग्रामर दोषपूर्ण क्षेत्र में प्रोग्राम के क्रियान्वयन की निगरानी करने के लिए एक डीबगर का या किसी अन्य उपकरण का इस्तेमाल कर सकता है और उस स्थान का पता लगा सकता है जिसमें प्रोग्राम अपने उद्देश्य से भटक गया है।
बग को पुनः प्रस्तुत करना अक्सर आसान नहीं होता है। कुछ बग प्रोग्राम की निविष्टियों द्वारा उत्पन्न होते हैं जिन्हें पुनः उत्पन्न करना प्रोग्रामर के लिए मुश्किल हो सकता है। थिरैक-25 विकिरण मशीन से हुई मौतों का एक कारण एक बग था (विशेष रूप से एक रेस कंडीशन) जो केवल उस समय उत्पन्न हुआ था जब मशीन संचालक ने एक उपचार योजना की प्रविष्टि बहुत अधिक तेजी से कर दी; इस कार्य के लिए सक्षम होने में कई दिनों का अभ्यास करना पड़ा था, इसलिए बग परीक्षण के दौरान या उस समय उत्पन्न नहीं हुआ था जब निर्माता ने इसकी नक़ल करने की कोशिश की थी। अन्य बग प्रोग्राम को एक डीबगर के जरिये चलाये जाने से गायब हो सकते हैं; ये हाइजेनबग्स होते हैं (हाइजेनबर्ग के अनिश्चितता के सिद्धांत पर मजाकिया तौर पर यह नाम दिया गया था).
डिबगिंग अभी भी एक उबाऊ कार्य है जिसके लिए काफी प्रयास की आवश्यकता होती है। 1990 के दशक से, विशेष रूप से एरियन 5 फ्लाइट 501 की दुर्घटना के बाद से डीबगिंग में प्रभावी स्वचालित सहयोग विकसित करने में नए सिरे से दिलचस्पी बढ़ी है। उदाहरण के लिए, काल्पनिक व्याख्या के जरिये परिवर्ती कोड विश्लेषण के तरीकों ने पहले से ही महत्वपूर्ण उपलब्धियां दी हैं, हालांकि अभी भी काफी हद तक बाकी बचा हुआ कार्य प्रगति में है।
जैसा कि किसी भी रचनात्मक कार्य के साथ होता है, कभी-कभी प्रेरणा की एक चमक भी एक समाधान दिखा देती है, लेकिन यह दुर्लभ है और परिभाषा के अनुसार, इस पर भरोसा नहीं किया जा सकता है।
बग के लिए कक्षाएं भी आयोजित की जाती हैं जिनका स्वयं कोड से कोई मतलब नहीं होता है। उदाहरण के लिए, अगर कोई एक दोषपूर्ण प्रलेखन या हार्डवेयर पर निर्भर है, कोड पूरी तरह से सही तरीके से उसी रूप में लिखा जा सकता है जैसा कि प्रलेखन कहता है लेकिन लेकिन बग वास्तव में प्रलेखन या हार्डवेयर में रहता है, कोड में नहीं। हालांकि, सिस्टम के अन्य भागों की बजाय कोड को बदलना आम है, क्योंकि इसे बदलने में समय और लागत आम तौर पर कम लगता है। सन्निहित प्रणालियों (एम्बेडेड सिस्टम्स) में हार्डवेयर बग के लिए अक्सर वर्कअराउंड होते हैं, क्योंकि हार्डवेयर का पुनर्निर्माण करने की तुलना में रोम (ROM) का एक नया संस्करण तैयार करना कहीं अधिक सस्ता होता है, विशेष रूप से अगर ये कमोडिटी आइटम होते हैं।

सुरक्षा संबंधी कमजोरियां

दुर्भावनापूर्ण सॉफ्टवेयर किसी सिस्टम में ज्ञात कमजोरियों का फायदा उठाने की कोशिश कर सकते हैं - जो बग हो सकते हैं और नहीं भी हो सकते हैं। वायरस अपने आप में बग नहीं होते हैं - वे आम तौर पर प्रोग्राम होते हैं जो साफ़ तौर पर वही करते हैं जिनके लिए उन्हें डिजाइन किया गया होता है। हालांकि वायरसों को लोकप्रिय प्रेस में कभी-कभी इसी रूप में संदर्भित किया जाता है।