सॉफ्टवेयर बग

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

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

इतिहास
मध्य अंग्रेजी शब्द wikt:bugge#Noun शब्दों के लिए आधार है wikt:bugbear#Noun और wikt:bug-a-boo#Noun एक राक्षस के लिए प्रयुक्त शब्दों के रूप में। दोषों का वर्णन करने के लिए बग शब्द 1870 के दशक से इंजीनियरिंग शब्दजाल का एक हिस्सा रहा है और इलेक्ट्रॉनिक्स और कंप्यूटरों की भविष्यवाणी करता है; यह मूल रूप से यांत्रिक खराबी का वर्णन करने के लिए हार्डवेयर इंजीनियरिंग में उपयोग किया गया हो सकता है। उदाहरण के लिए, थॉमस एडीसन ने 1878 में एक सहयोगी को लिखे पत्र में लिखा था:

"... difficulties arise—this thing gives out and [it is] then that 'Bugs'—as such little faults and difficulties are called—show themselves" बाफल बॉल, पहला मैकेनिकल पिनबॉल गेम, 1931 में कीड़ों से मुक्त होने के रूप में विज्ञापित किया गया था। द्वितीय विश्व युद्ध के दौरान सैन्य गियर के साथ समस्याओं को बग (या ग्लिट्स) कहा जाता था। 1942 में प्रकाशित एक पुस्तक में, लुईस डिकिंसन रिच ने एक संचालित बर्फ काटने वाली मशीन के बारे में बात करते हुए कहा, बर्फ काटने को तब तक के लिए निलंबित कर दिया गया था जब तक कि निर्माता को अपने प्रिय से कीड़े निकालने के लिए नहीं लाया जा सकता था।

इसहाक असिमोव ने 1944 में प्रकाशित अपनी लघु कहानी कैच दैट रैबिट में रोबोट के मुद्दों से संबंधित होने के लिए बग शब्द का इस्तेमाल किया।

बग शब्द का उपयोग कंप्यूटर अग्रणी ग्रेस हूपर द्वारा एक खाते में किया गया था, जिन्होंने एक प्रारंभिक इलेक्ट्रोमैकेनिकल कंप्यूटर में खराबी के कारण को प्रचारित किया था। कहानी का एक विशिष्ट संस्करण है:

"In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug." जब बग पाया गया तो हूपर मौजूद नहीं था, लेकिन यह उसकी पसंदीदा कहानियों में से एक बन गई। लॉग बुक में तारीख 9 सितंबर, 1947 थी। जिन ऑपरेटरों ने इसे पाया, उनमें विलियम बिल बर्क, बाद में नेवल सरफेस वारफेयर सेंटर डहलग्रेन डिवीजन, डहलग्रेन, वर्जीनिया, शामिल थे। इंजीनियरिंग की शब्दावली से परिचित थे और मनोरंजक तरीके से कीट को इस संकेतन के साथ रखा कि बग का पहला वास्तविक मामला पाया जा रहा है। संलग्न कीट के साथ पूर्ण यह लॉग बुक, अमेरिकी इतिहास के स्मिथसोनियन राष्ट्रीय संग्रहालय के संग्रह का हिस्सा है।

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

"... an analysing process must equally have been performed in order to furnish the Analytical Engine with the necessary operative data; and that herein may also lie a possible source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders."

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

सरकारी शोधकर्ता, कंपनियाँ और साइबर सुरक्षा विशेषज्ञ वे लोग हैं जो आमतौर पर सॉफ़्टवेयर की खामियों का पता लगाते हैं। रिपोर्ट में कंप्यूटर अपराध और कॉपीराइट कानूनों में सुधार की मांग की गई है। "The Computer Fraud and Abuse Act, the Digital Millennium Copyright Act and the Electronic Communications Privacy Act criminalize and create civil penalties for actions that security researchers routinely engage in while conducting legitimate security research, the report said."

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

सॉफ्टवेयर इंजीनियरिंग में, गलती कायापलट (ग्रीक मेटा = परिवर्तन, रूप = रूप से) सॉफ्टवेयर परिनियोजन के अंतिम चरण में एक दोष के विकास को संदर्भित करता है। सॉफ़्टवेयर विकास जीवनचक्र के प्रारंभिक चरणों में एक विश्लेषक द्वारा की गई गलती का परिवर्तन, जो चक्र के अंतिम चरण में एक दोष की ओर ले जाता है, इसे 'गलती कायापलट' कहा जाता है। रेफ नाम = रूपांतर> 

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

रोकथाम
सॉफ़्टवेयर उद्योग ने बगों की संख्या कम करने के लिए बहुत प्रयास किए हैं। इसमे शामिल है:

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

विकास के तरीके
कई योजनाएँ प्रोग्रामर गतिविधि को प्रबंधित करने में सहायता करती हैं ताकि कम बग उत्पन्न हों। सॉफ्टवेयर इंजीनियरिंग (जो सॉफ़्टवेयर डिज़ाइन के मुद्दों को भी संबोधित करती है) दोषों को रोकने के लिए कई तकनीकों को लागू करती है। उदाहरण के लिए, औपचारिक कार्यक्रम विनिर्देश कार्यक्रमों के सटीक व्यवहार को बताते हैं ताकि डिज़ाइन बग को समाप्त किया जा सके। दुर्भाग्य से, औपचारिक विनिर्देश किसी भी चीज के लिए अव्यावहारिक हैं, लेकिन कम से कम कार्यक्रमों के लिए, दहनशील विस्फोट और गैर-नियतात्मक एल्गोरिदम की समस्याओं के कारण।

इकाई का परीक्षण में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना शामिल है जिसे प्रोग्राम को परफॉर्म करना है।

परीक्षण-संचालित विकास में इकाई परीक्षण कोड से पहले लिखे जाते हैं और कोड को तब तक पूर्ण नहीं माना जाता जब तक कि सभी परीक्षण सफलतापूर्वक पूर्ण नहीं हो जाते।

चुस्त सॉफ्टवेयर विकास में अपेक्षाकृत छोटे बदलावों के साथ लगातार सॉफ्टवेयर रिलीज शामिल होते हैं। उपयोगकर्ता प्रतिक्रिया से दोष प्रकट होते हैं।

ओपन सोर्स डेवलपमेंट किसी को भी सोर्स कोड की जांच करने की अनुमति देता है। लिनस के नियम के रूप में एरिक एस. रेमंड द्वारा लोकप्रिय विचार के एक स्कूल का कहना है कि लोकप्रिय खुला स्रोत सॉफ्टवेयर में अन्य सॉफ़्टवेयर की तुलना में कम या कोई बग नहीं होने की अधिक संभावना है, क्योंकि पर्याप्त नेत्रगोलक दिए जाने पर, सभी बग उथले हैं। हालांकि, यह दावा विवादित रहा है: कंप्यूटर सुरक्षा विशेषज्ञ इलियास लेवी ने लिखा है कि जटिल, कम समझ में आने वाले और बिना दस्तावेज वाले स्रोत कोड में कमजोरियों को छिपाना आसान है, क्योंकि भले ही लोग कोड की समीक्षा कर रहे हों, इसका मतलब यह नहीं है कि वे योग्य हैं ऐसा करने के लिए। ओपन-सोर्स सॉफ़्टवेयर बग का एक उदाहरण डेबियन#2008 ओपनएसएसएल भेद्यता थी।

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

कोड विश्लेषण
स्टेटिक कोड विश्लेषण के लिए उपकरण संभावित समस्याओं का पता लगाने के लिए कंपाइलर की क्षमताओं से परे प्रोग्राम टेक्स्ट का निरीक्षण करके डेवलपर्स की मदद करते हैं। हालांकि आम तौर पर एक विनिर्देश दिए गए सभी प्रोग्रामिंग त्रुटियों को खोजने की समस्या हल करने योग्य नहीं है (देखें रुकने की समस्या), ये उपकरण इस तथ्य का फायदा उठाते हैं कि मानव प्रोग्रामर अक्सर सॉफ़्टवेयर लिखते समय कुछ प्रकार की सरल गलतियाँ करते हैं।

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

परीक्षण
सॉफ़्टवेयर परीक्षक वे लोग होते हैं जिनका प्राथमिक कार्य बग ढूंढना या परीक्षण का समर्थन करने के लिए कोड लिखना होता है। कुछ परियोजनाओं पर, कार्यक्रम विकसित करने की तुलना में परीक्षण पर अधिक संसाधन खर्च किए जा सकते हैं।

परीक्षण के दौरान माप शेष संभावित बगों की संख्या का अनुमान प्रदान कर सकते हैं; यह अधिक विश्वसनीय हो जाता है क्योंकि किसी उत्पाद का परीक्षण और विकास किया जाता है।

डिबगिंग


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

हालाँकि, डिबगर की सहायता से भी, बग्स का पता लगाना एक कला है। किसी प्रोग्राम के एक सेक्शन में बग के लिए यह असामान्य नहीं है कि वह पूरी तरह से अलग सेक्शन में फेल हो जाए, इस प्रकार इसे ट्रैक करना विशेष रूप से कठिन बना देता है (उदाहरण के लिए, ग्राफिक्स रेंडरिंग (कंप्यूटर ग्राफिक्स) रूटीन में एक त्रुटि जिसके कारण फ़ाइल इनपुट/आउटपुट | I/O रूटीन विफल हो जाता है), सिस्टम के एक स्पष्ट रूप से असंबंधित हिस्से में।

कभी-कभी, एक बग एक अकेला दोष नहीं होता है, लेकिन प्रोग्रामर की ओर से सोचने या योजना बनाने में त्रुटि का प्रतिनिधित्व करता है। ऐसी तार्किक त्रुटियों के लिए प्रोग्राम के एक हिस्से को ओवरहाल या फिर से लिखने की आवश्यकता होती है। कोड समीक्षा के एक भाग के रूप में, कोड के माध्यम से आगे बढ़ने और निष्पादन प्रक्रिया की कल्पना या लिप्यंतरण करने से अक्सर बग को पुन: पेश किए बिना त्रुटियां मिल सकती हैं।

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

इनपुट से कुछ बग का पता चलता है जो प्रोग्रामर के लिए फिर से बनाना मुश्किल हो सकता है। थेराक-25 विकिरण मशीन से होने वाली मौतों का एक कारण एक बग (विशेष रूप से, एक दौड़ की स्थिति) था जो केवल तब हुआ जब मशीन ऑपरेटर ने बहुत तेजी से एक उपचार योजना में प्रवेश किया; ऐसा करने में सक्षम होने में अभ्यास के कई दिन लग गए, इसलिए बग परीक्षण में प्रकट नहीं हुआ या जब निर्माता ने इसे डुप्लिकेट करने का प्रयास किया। बग को खोजने में मदद करने के लिए जब भी सेटअप बढ़ाया जाता है, तो अन्य बग होने बंद हो सकते हैं, जैसे प्रोग्राम को डीबगर के साथ चलाना; इन्हें heisenbug्स कहा जाता है (हास्यास्पद रूप से अनिश्चितता सिद्धांत के नाम पर)।

1990 के दशक के बाद से, विशेष रूप से एरियन 5 फ्लाइट 501 आपदा के बाद, डिबगिंग के लिए स्वचालित सहायता में रुचि बढ़ी, जैसे अमूर्त व्याख्या द्वारा स्थिर कोड विश्लेषण। बग के कुछ वर्गों का कोड से कोई लेना-देना नहीं है। दोषपूर्ण दस्तावेज़ीकरण या हार्डवेयर सिस्टम उपयोग में समस्याएँ पैदा कर सकता है, भले ही कोड दस्तावेज़ीकरण से मेल खाता हो। कुछ मामलों में, कोड में परिवर्तन समस्या को समाप्त कर देते हैं, भले ही कोड तब प्रलेखन से मेल नहीं खाता हो। अंतः स्थापित प्रणाली अक्सर हार्डवेयर बग्स को हल करते हैं, क्योंकि रीड ऑनली मैमोरी का एक नया संस्करण बनाना हार्डवेयर को फिर से बनाने की तुलना में बहुत सस्ता है, खासकर अगर वे कमोडिटी आइटम हैं।

बग का बेंचमार्क
परीक्षण और डिबगिंग पर पुनरुत्पादित अनुसंधान को सुविधाजनक बनाने के लिए, शोधकर्ता बग के क्यूरेटेड बेंचमार्क का उपयोग करते हैं:
 * सीमेंस बेंचमार्क
 * कई बग नौ ओपन-सोर्स प्रोग्राम में 185 सी बग का बेंचमार्क है।
 * दोष4J 5 ओपन-सोर्स प्रोजेक्ट्स से 341 Java बग्स का एक बेंचमार्क है। इसमें संबंधित पैच होते हैं, जो विभिन्न प्रकार के पैच को कवर करते हैं।
 * भालू परीक्षण विफलताओं पर ध्यान केंद्रित करते हुए निरंतर एकीकरण निर्माण विफलताओं का एक बेंचमार्क है। ट्रैविस सीआई पर ओपन-सोर्स प्रोजेक्ट्स से बिल्ड की निगरानी करके इसे बनाया गया है।

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

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

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

प्राथमिकता
नियोजित परिवर्तनों की सूची में बग आने पर प्राथमिकता नियंत्रण। प्रत्येक सॉफ्टवेयर निर्माता द्वारा प्राथमिकता तय की जाती है। प्राथमिकताएं संख्यात्मक हो सकती हैं, जैसे 1 से 5, या नामित, जैसे महत्वपूर्ण, उच्च, निम्न, या स्थगित। ये रेटिंग स्केल गंभीरता रेटिंग के समान या समान हो सकते हैं, लेकिन बग की गंभीरता को ठीक करने के अनुमानित प्रयास के संयोजन के रूप में मूल्यांकन किया जाता है; कम गंभीरता वाला लेकिन आसानी से ठीक होने वाला बग मध्यम गंभीरता वाले बग की तुलना में उच्च प्राथमिकता प्राप्त कर सकता है जिसे ठीक करने के लिए अत्यधिक प्रयास की आवश्यकता होती है। प्राथमिकता रेटिंग को उत्पाद रिलीज़ के साथ संरेखित किया जा सकता है, जैसे कि महत्वपूर्ण प्राथमिकता उन सभी बगों को इंगित करती है जिन्हें अगले सॉफ़्टवेयर रिलीज़ से पहले ठीक किया जाना चाहिए।

उत्पाद की रिलीज में देरी या रोक लगाने के लिए पर्याप्त गंभीर बग को शो स्टॉपर कहा जाता है इसका नाम इसलिए रखा गया है क्योंकि यह शो को रोकता है - अस्वीकार्य उत्पाद विफलता का कारण बनता है।

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

किसी सॉफ़्टवेयर प्रकाशक द्वारा किसी विशेष बग को पैच न करने या यहां तक ​​कि उसे ठीक न करने का विकल्प चुनने के कारणों में शामिल हैं:
 * एक समय सीमा पूरी होनी चाहिए और समय सीमा तक सभी बग को ठीक करने के लिए संसाधन अपर्याप्त हैं।
 * आगामी रिलीज़ में बग को पहले ही ठीक कर लिया गया है, और यह उच्च प्राथमिकता का नहीं है।
 * बग को ठीक करने के लिए आवश्यक परिवर्तन बहुत महंगे हैं या बहुत से अन्य घटकों को प्रभावित करते हैं, जिसके लिए एक प्रमुख परीक्षण गतिविधि की आवश्यकता होती है।
 * यह संदेहास्पद या ज्ञात हो सकता है कि कुछ उपयोगकर्ता मौजूदा बग्गी व्यवहार पर भरोसा कर रहे हैं; एक प्रस्तावित सुधार एक विकट:ब्रेकिंग परिवर्तन पेश कर सकता है।
 * समस्या एक ऐसे क्षेत्र में है जो आगामी रिलीज़ के साथ अप्रचलित हो जाएगा; इसे ठीक करना अनावश्यक है।
 * यह एक बग नहीं है, यह एक सुविधा है । अपेक्षित और कथित व्यवहार या गैर-दस्तावेज विशेषता के बीच एक गलतफहमी पैदा हो गई है।

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

बग की एक अन्य श्रेणी को दौड़ की स्थिति कहा जाता है जो तब हो सकती है जब प्रोग्राम में एक ही समय में कई घटक निष्पादित होते हैं। यदि घटक डेवलपर के इरादे से अलग क्रम में बातचीत करते हैं, तो वे एक दूसरे के साथ हस्तक्षेप कर सकते हैं और कार्यक्रम को अपने कार्यों को पूरा करने से रोक सकते हैं। इन बगों का पता लगाना या अनुमान लगाना मुश्किल हो सकता है, क्योंकि वे किसी प्रोग्राम के प्रत्येक निष्पादन के दौरान नहीं हो सकते हैं।

वैचारिक त्रुटियां एक डेवलपर की गलतफहमी है कि सॉफ्टवेयर को क्या करना चाहिए। परिणामी सॉफ़्टवेयर डेवलपर की समझ के अनुसार प्रदर्शन कर सकता है, लेकिन वह नहीं जो वास्तव में आवश्यक है। अन्य प्रकार:

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

नियंत्रण प्रवाह
नियंत्रण प्रवाह बग वे हैं जो वैध तर्क के साथ प्रक्रियाओं में पाए जाते हैं, लेकिन इससे अनपेक्षित परिणाम होते हैं, जैसे अनंत लूप और अनंत रिकर्सन (कंप्यूटर विज्ञान), सशर्त बयानों के लिए गलत तुलना जैसे गलत असमानता का उपयोग करना, और ऑफ-बाय-वन त्रुटियां (लूप करते समय एक बहुत अधिक या एक बहुत कम पुनरावृत्तियों को गिनना)।

इंटरफेसिंग

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

मल्टी-थ्रेडिंग

 * गतिरोध, जहाँ कार्य A तब तक जारी नहीं रह सकता जब तक कि कार्य B समाप्त नहीं हो जाता, लेकिन उसी समय, कार्य B तब तक जारी नहीं रह सकता जब तक कि कार्य A समाप्त नहीं हो जाता।
 * दौड़ की स्थिति, जहां कंप्यूटर प्रोग्रामर के इच्छित क्रम में कार्य नहीं करता है।
 * महत्वपूर्ण वर्गों में समवर्ती त्रुटियां, आपसी बहिष्करण और समवर्ती प्रोग्रामिंग की अन्य विशेषताएं # संसाधनों तक पहुंच का समन्वय। टाइम-ऑफ-चेक-टू-टाइम-ऑफ-यूज (TOCTOU) असुरक्षित महत्वपूर्ण अनुभाग का एक रूप है।

संसाधन

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

सिंटेक्स

 * गलत लेक्सिकल_विश्लेषण # टोकन का उपयोग, जैसे कि ==# समानता के बजाय असाइनमेंट करना। उदाहरण के लिए, कुछ भाषाओं में x=5 x का मान 5 पर सेट करेगा जबकि x==5 जाँच करेगा कि x वर्तमान में 5 है या कोई अन्य संख्या। व्याख्या की गई भाषाएँ ऐसे कोड को विफल होने देती हैं। परीक्षण शुरू होने से पहले संकलित भाषाएँ ऐसी त्रुटियों को पकड़ सकती हैं।

टीम वर्क

 * अप्रचारित अद्यतन; उदा. प्रोग्रामर myAdd को बदल देता है लेकिन mySubtract को बदलना भूल जाता है, जो उसी एल्गोरिथम का उपयोग करता है। इन त्रुटियों को डोंट रिपीट योरसेल्फ | डोंट रिपीट योरसेल्फ फिलॉसफी द्वारा कम किया जाता है।
 * टिप्पणियाँ पुरानी या गलत हैं: कई प्रोग्रामर मानते हैं कि टिप्पणियाँ कोड का सटीक वर्णन करती हैं।
 * प्रलेखन और उत्पाद के बीच अंतर।

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

कीड़ों से होने वाली क्षति के अलावा, उनकी कुछ लागत उन्हें ठीक करने में किए गए प्रयास के कारण होती है। 1978 में, लिएंट्ज़ एट अल। दिखाया गया है कि बग फिक्सिंग में परियोजनाओं का माध्य विकास के प्रयास का 17 प्रतिशत निवेश करता है। 2020 में GitHub रिपॉजिटरी पर शोध में दिखाया गया है कि माध्य 20% है।

वितरित उत्पाद में अवशिष्ट बग
1994 में, नासा के गोडार्ड अंतरिक्ष उड़ान केंद्र ने त्रुटियों की औसत संख्या 4.5 प्रति 1000 लाइन कोड (कोड की सोर्स लाइन) से घटाकर 1 प्रति 1000 SLOC करने में कामयाबी हासिल की। 1990 में एक अन्य अध्ययन ने बताया कि असाधारण रूप से अच्छी सॉफ्टवेयर विकास प्रक्रियाएँ 0.1 प्रति 1000 SLOC के रूप में परिनियोजन विफलता दर प्राप्त कर सकती हैं। यह आंकड़ा साहित्य में पुनरावृत्त है जैसे स्टीव मैककोनेल द्वारा कोड पूर्ण, और नासा अध्ययन उड़ान सॉफ्टवेयर जटिलता पर। कुछ परियोजनाओं में शून्य दोष भी पाए गए: आईबीएम व्हीलराइटर टाइपराइटर में फर्मवेयर जिसमें 63,000 एसएलओसी शामिल हैं, और 500,000 एसएलओसी के साथ अंतरिक्ष शटल सॉफ्टवेयर।

प्रसिद्ध बग
कई सॉफ़्टवेयर बग प्रसिद्ध हो गए हैं, आमतौर पर उनकी गंभीरता के कारण: उदाहरणों में विभिन्न अंतरिक्ष और सैन्य विमान दुर्घटनाएं शामिल हैं। संभवतः सबसे प्रसिद्ध बग वर्ष 2000 की समस्या या Y2K बग है, जिसके कारण 19xx से 20xx तारीखों में परिवर्तन से बहुत पहले लिखे गए कई कार्यक्रम खराब हो गए थे, उदाहरण के लिए 25 दिसंबर 04 जैसी तारीख को 1904 में मानते हुए, 19100 के बजाय 19100 प्रदर्शित करना 2000, और इतने पर। 20वीं शताब्दी के अंत में एक बड़े प्रयास ने सबसे गंभीर समस्याओं का समाधान किया, और कोई बड़ा परिणाम नहीं हुआ।

नाइट कैपिटल ग्रुप # 2012 स्टॉक ट्रेडिंग व्यवधान में पुराने एपीआई और नए एपीआई के बीच एक ऐसी असंगति शामिल थी।

लोकप्रिय संस्कृति में

 * 1968 के उपन्यास 2001: ए स्पेस ओडिसी (उपन्यास) | 2001: ए स्पेस ओडिसी और संबंधित 1968 फिल्म 2001: ए स्पेस ओडिसी (फिल्म) दोनों में | 2001: ए स्पेस ओडिसी, एक अंतरिक्ष यान का ऑनबोर्ड कंप्यूटर, एचएएल 9000, करने का प्रयास करता है इसके सभी चालक दल के सदस्यों को मार डालो। अनुवर्ती 1982 के उपन्यास, 2010: ओडिसी टू, और साथ में 1984 की फिल्म, 2010 (फ़िल्म) में, यह पता चला है कि यह क्रिया कंप्यूटर द्वारा दो परस्पर विरोधी उद्देश्यों के साथ प्रोग्राम किए जाने के कारण हुई थी: इसकी सभी सूचनाओं को पूरी तरह से प्रकट करने के लिए, और चालक दल से उड़ान के असली उद्देश्य को गुप्त रखना; इस संघर्ष के कारण HAL पागल हो गया और अंततः मानवघाती हो गया।
 * नेना 1983 के गीत 99 गुब्बारे (99 लाल गुब्बारे) के अंग्रेजी संस्करण में सॉफ्टवेयर में बग के परिणामस्वरूप, 99 लाल गुब्बारों के एक समूह की रिहाई को दुश्मन के परमाणु मिसाइल लॉन्च के लिए गलत माना जाता है, जिसके लिए एक समान लॉन्च प्रतिक्रिया की आवश्यकता होती है, जिसके परिणामस्वरूप तबाही होती है।
 * 1999 की अमेरिकी कॉमेडी कार्यालय की जगह में, तीन कर्मचारियों ने एक कंप्यूटर वायरस का उपयोग करके Y2K कंप्यूटर बग के साथ अपनी कंपनी की व्यस्तता का फायदा उठाने का प्रयास (असफल) किया, जो उनके बैंक खाते में एक पैसे के राउंड-ऑफ अंश भेजता है - एक लंबे समय से ज्ञात तकनीक के रूप में वर्णित है। सलामी टुकड़ा करने की रणनीति।
 * 2004 का उपन्यास द बग, एलेन उल्मैन द्वारा, डेटाबेस एप्लिकेशन में एक मायावी बग खोजने के प्रोग्रामर के प्रयास के बारे में है।
 * 2008 की कनाडाई फिल्म नियंत्रण ऑल्ट डिलीट (फ़िल्म)फिल्म) 1999 के अंत में एक कंप्यूटर प्रोग्रामर के बारे में है जो अपनी कंपनी में वर्ष 2000 की समस्या से संबंधित बग को ठीक करने के लिए संघर्ष कर रहा है।

यह भी देखें

 * विरोधी पैटर्न
 * बग बाउंटी प्रोग्राम
 * गड़बड़ी दूर करना
 * हार्डवेयर बग
 * ISO/IEC 9126, जो बग को दोष या गैर-अनुरूपता के रूप में वर्गीकृत करता है
 * ऑर्थोगोनल दोष वर्गीकरण
 * रेसट्रैक समस्या
 * जोखिम डाइजेस्ट
 * सॉफ्टवेयर दोष सूचक
 * सॉफ्टवेयर प्रतिगमन
 * सॉफ्टवेयर सड़ांध
 * स्वचालित बग फिक्स

इस पेज में लापता आंतरिक लिंक की सूची

 * असर
 * सोर्स कोड
 * सुरक्षा कीड़े
 * मांग
 * दोष (प्रौद्योगिकी)
 * व्यापार महकमा
 * मानक और प्रौद्योगिकी का राष्ट्रीय संस्थान
 * गड़बड़
 * बर्फ काटना
 * उस खरगोश को पकड़ो
 * अमेरिकी इतिहास का राष्ट्रीय संग्रहालय
 * तर्क त्रुटि
 * गैर नियतात्मक एल्गोरिथम
 * परीक्षण संचालित विकास
 * मिश्रित विस्फोट
 * सीमा जाँच
 * सूचक (कंप्यूटर प्रोग्रामिंग)
 * रखरखाव का खर्च
 * जाँच टाइप करें
 * भाषा का अंकन
 * स्थैतिक कोड विश्लेषण
 * अड़चन (इंजीनियरिंग)
 * सॉफ्टवेयर परीक्षक
 * को़ड समीक्षा
 * प्रतिपादन (कंप्यूटर ग्राफिक्स)
 * सार व्याख्या
 * अनिश्चित सिद्धांत
 * वैकल्पिक हल
 * अप्रमाणित सुविधा
 * ऑफ-बाय-वन एरर
 * अंकगणितीय अंतर्प्रवाह
 * अंकगणितीय परिशुद्धता
 * अंकगणितीय अतिप्रवाह
 * बहाव को काबू करें
 * आपसी बहिष्कार
 * अप्रारंभीकृत चर
 * स्टैक ओवरफ़्लो
 * भंडारण का उल्लंघन
 * उपयोग का उल्लंघन
 * पैक दशमलव
 * नल पॉइंटर
 * सार्वजनिक परिवाहन
 * परमाणु शक्ति
 * विमानन
 * कोड की स्रोत पंक्तियाँ
 * 2010 (फिल्म)
 * पेज 9000
 * स्वचालित बग फिक्सिंग

बाहरी संबंध

 * "Common Weakness Enumeration" – an expert webpage focus on bugs, at NIST.gov
 * BUG type of Jim Gray – another Bug type
 * "The First Computer Bug!" – an email from 1981 about Adm. Hopper's bug
 * "Toward Understanding Compiler Bugs in GCC and LLVM". A 2016 study of bugs in compilers
 * "Toward Understanding Compiler Bugs in GCC and LLVM". A 2016 study of bugs in compilers