हम प्रोग्राम क्रैश के बारे में जानकारी के संग्रह को स्वचालित करते हैं

प्रसिद्ध कहावत का विरोध करने के लिए: "जो कुछ भी सांकेतिक शब्दों में बदलना नहीं करता है वह बग नहीं बनाता है।" प्रत्येक डेवलपर जानता है कि कैसे और बग बनाने के लिए प्यार करता है, लेकिन बाद में उन्हें ठीक करना पसंद नहीं करता है। एक मामले में कोड में त्रुटियां केवल प्रोग्राम द्वारा गलत डेटा प्रोसेसिंग की ओर ले जाती हैं, और दूसरे में अपवाद (क्रैश, क्रैश, क्रैश)। इस पोस्ट में, मैं इस बारे में बात करूँगा कि कैसे आप किसी प्रोग्राम की क्रैश के बारे में डेटा के संग्रह को स्वचालित कर सकते हैं और त्रुटियों को ठीक करते हुए अपने जीवन को सरल बना सकते हैं।

क्या आप जानते हैं कि जब मैंने एक मित्र को बताया कि मैं उस परियोजना में एक पुस्तकालय का उपयोग करना चाहता हूं जो त्रुटि डेटा के संग्रह को स्वचालित करता है? मैंने सचमुच निम्नलिखित बात सुनी: “किसी को इस तरह की जटिल प्रणाली की आवश्यकता क्यों होगी? देखिए, अगर मेरे कार्यक्रम में कुछ होता है, तो उपयोगकर्ता मुझे एक पत्र लिखते हैं, उन्होंने कौन से बटन दबाए और उन्होंने क्या किया। और फिर मैं त्रुटि को पुन: पेश करता हूं और इसे ठीक करता हूं। "

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

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

जब कोई उपयोगकर्ता मदद के लिए ईमेल भेजता है तो मैं आमतौर पर क्या करता हूं?

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

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

जब कोई उपयोगकर्ता मेरे अनुरोध का उत्तर देता है, तो लगभग हमेशा मेरे पास अतिरिक्त प्रश्न होते हैं: "लेकिन इस बटन पर क्लिक करने और इस और उस विकल्प को बदलने का प्रयास करें।" जवाब में मुझे चुप्पी मिलती है। उपयोगकर्ता के पास कई बार ऐसा करने का धैर्य नहीं होता है जब तक मुझे उसकी वह सारी जानकारी नहीं मिल जाती है जिसकी मुझे आवश्यकता है।

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

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

सामान्य तौर पर, बग का विश्लेषण करते समय, मेरा मुख्य लक्ष्य मेरी मशीन पर इस बग को पुन: पेश करना है। यह मुझे इसे ठीक करने की अनुमति देगा। उपयोगकर्ता के शब्दों से यह शायद ही कभी स्पष्ट होता है कि वह आवेदन को कैसे दुर्घटनाग्रस्त करता है, वह आवेदन में अपवाद को कैसे प्रबंधित करता है? इस प्रश्न का उत्तर देना मुश्किल है, आपकी आँखों के सामने केवल लॉग में पाठ का एक गुच्छा है।

इसलिए, उपयोगकर्ता के साथ मेरे संचार में अगला कदम यह है कि वह एक स्क्रीनशॉट ले या एक वीडियो रिकॉर्ड करे जिसमें वह अपने कार्यों को दिखाएगा, कि वह आवेदन में त्रुटि कैसे प्राप्त करता है। क्या आपको लगता है कि बहुत सारे उपयोगकर्ता मुझे एक वीडियो भेजते हैं? नहीं, लेकिन, फिर भी, ऐसे शिल्पकार मुझसे मिले हैं। और इस तरह के वीडियो कभी-कभी त्रुटि को दोहराने के लिए सबसे उपयोगी चीज थी।

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

कैसे, आखिरकार, त्रुटि जानकारी एकत्र करना बेहतर है - मैन्युअल या स्वचालित रूप से?

2000 के दशक के प्रारंभ में Microsoft संग्रह [1] में स्वत: संग्रह और त्रुटि रिपोर्ट देने का विचार आया, जब वे कई उत्पादों (विंडोज और कार्यालय सहित) में उत्पन्न त्रुटियों की एक जय से गूंज उठे। विंडोज डेवलपमेंट टीम ने सिस्टम के कोर को डंप करने के लिए एक टूल विकसित किया, जिसका विश्लेषण तब किया जा सकता था।

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

इस विकास को विंडोज त्रुटि रिपोर्टिंग (WER) कहा गया और इसे Windows XP में लागू किया गया। तब से, सभी Microsoft उत्पादों ने WER त्रुटियों को पकड़ लिया है। Microsoft उत्पादों में WER का उपयोग करने की प्रभावशीलता पर निम्नलिखित आँकड़े [2] हैं:

• "शीर्ष" की गई त्रुटियों का 20 प्रतिशत सही करने से ग्राहक समस्याओं का 80 प्रतिशत हल हो सकता है;
• केवल 1 प्रतिशत त्रुटियों का कारण सुधार कर, ग्राहक की 50 प्रतिशत समस्याओं को ठीक किया जा सकता है।

कोई भी डेवलपर अपने एप्लिकेशन में त्रुटि डेटा के संग्रह को स्वचालित करने के लिए WER का उपयोग कर सकता है। WER Microsoft सर्वर पर एक त्रुटि रिपोर्ट भेजता है, और डेवलपर इस सर्वर को "मुफ़्त में" एक्सेस कर सकता है। लेकिन इसके लिए आपके पास VeriSign सर्टिफिकेट होना जरूरी है। इस तरह के प्रमाणपत्र को खरीदने पर प्रति वर्ष $ 500 का खर्च आता है। वास्तव में, यदि आप विंडोज के लिए विकसित कर रहे हैं, तो आपको एक प्रमाण पत्र खरीदने की आवश्यकता है, इसलिए हम मान लेंगे कि आप मुफ्त में WER सर्वर तक पहुंच सकते हैं।

WER के अलावा, प्रोग्राम क्रैश पर डेटा एकत्र करने के लिए अन्य मुफ्त पुस्तकालय हैं। उदाहरण के लिए, विंडोज पर मेरी सी ++ परियोजनाओं में, मैं एक खुला स्रोत पुस्तकालय का उपयोग करता हूं जिसका नाम क्रैशरप्ट [3] है। मैं linuxoids को सलाह दे सकता हूं कि वे खुले Google लाइब्रेरी ब्रेकपैड [4] का उपयोग करें।

व्यक्तिगत रूप से, मैं क्रैशर पसंद करता हूं, क्योंकि मैं केवल विंडोज के तहत लिखता हूं। इसके अलावा, यह लाइब्रेरी आपको न केवल HTTP के माध्यम से सर्वर को त्रुटि रिपोर्ट फाइल भेजने की अनुमति देती है, बल्कि मेरे मेलबॉक्स के पत्र के रूप में भी है, जो मेरे लिए अधिक सुविधाजनक है। आगे मैं आपको बताऊंगा कि यह लाइब्रेरी और क्या कर सकती है।

क्या त्रुटि डेटा स्वचालित रूप से एकत्र किया जा सकता है?

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

जब कोई अपवाद होता है, क्रैशर हैंडलर लॉन्च किया जाता है, जो सबसे पहले, अपवाद बिंदुओं को बचाता है (यह अपवाद पते, इसकी कोड और प्रकार वाली संरचना है)। इसके बाद, CrashRpt एक नई प्रक्रिया शुरू करता है और इसके लिए अपवाद बिंदुओं को पारित करता है। मूल आवेदन जिसमें अपवाद हुआ वह अस्थिर हो सकता है और सभी त्रुटि डेटा पुनर्प्राप्त होते ही समाप्त हो जाएगा।

मिनीडम्प

नई प्रक्रिया में, मुख्य कार्य त्रुटि डेटा एकत्र करने वाला है।

सबसे पहले, Microsoft से dbghelp.dll सिस्टम लाइब्रेरी का उपयोग करके एक मिनीडंप लिखा जाता है। ऐसा करने के लिए, मूल प्रक्रिया के सभी थ्रेड निलंबित हैं, और प्रक्रिया का एक "स्नैपशॉट" किया जाता है। प्रक्रिया में लोड किए गए सभी DLL मॉड्यूल के नाम और संस्करण रिकॉर्ड किए गए हैं। प्रक्रिया में काम करने वाले थ्रेड्स के पहचानकर्ता सहेजे जाते हैं। स्टैक का एक स्नैपशॉट प्रत्येक थ्रेड के लिए रिकॉर्ड किया गया है। मिनीपंप ऑपरेटिंग सिस्टम के संस्करण, सीपीयू की संख्या और उनके ब्रांड के बारे में जानकारी संग्रहीत करता है। कई दस किलो किलोबाइट के क्रम के एक मिनीडम्प का वजन होता है।

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

लॉग

प्रोग्राम क्रैश के बारे में जानकारी के संग्रह को स्वचालित करना हमें सामान्य लॉग को छोड़ने के लिए मजबूर नहीं करता है। हम पहले की तरह, लॉग में वर्तमान संचालन लिख सकते हैं, और क्रैश होने पर, त्रुटि रिपोर्ट में लॉग स्वचालित रूप से जुड़ जाएगा। यह गलतफहमी को समाप्त करता है जो पहले "मैनुअल" उपयोगकर्ता लॉग अनुरोधों के साथ उत्पन्न हो सकती है। अब प्रोग्राम क्रैश होने पर लॉग में हमेशा अप-टू-डेट डेटा होगा, और उपयोगकर्ता को यह समझाने की ज़रूरत नहीं होगी कि छिपे हुए लोकलऐपडैट फ़ोल्डर को कैसे खोलें और वहाँ से क्या फ़ाइल प्राप्त करें।

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

स्क्रीनशॉट

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

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

इसलिए, त्रुटि के बारे में एक बहुत ही उपयोगी जानकारी दुर्घटना के समय उपयोगकर्ता की स्क्रीन का एक स्क्रीनशॉट है। CrashRpt पुस्तकालय आपको स्वचालित रूप से इस तरह के स्क्रीनशॉट को बनाने की अनुमति देता है, इसे JPEG प्रारूप (संपीड़न गुणवत्ता अनुकूलित किया जा सकता है) या PNG में सहेजता है। परिणामस्वरूप, मैं देख सकता हूं कि त्रुटि के समय उपयोगकर्ता ने कौन सा बटन दबाया था, जो, मेरा मानना ​​है, त्रुटि को पुन: पेश करने में बहुत मदद करता है।

नीचे दिए गए चित्र में, मैंने एप्लिकेशन क्रैश के समय लिए गए स्क्रीनशॉट का एक उदाहरण दिया। स्क्रीनशॉट में केवल एप्लिकेशन विंडो क्षेत्र होता है, शेष क्षेत्र स्वचालित रूप से काले रंग के होते हैं (हम उपयोगकर्ता की गोपनीयता की रक्षा करते हैं)।

वीडियो

याद रखें, मैंने कहा कि कई बार उपयोगकर्ता मुझे वीडियो भेजते हैं जो प्रोग्राम के दुर्घटनाग्रस्त होने से तुरंत पहले किए गए कार्यों को दर्शाते हैं? तो, क्रैश लाइब्रेरी के साथ आपको वीडियो बनाने के लिए उपयोगकर्ता से भीख नहीं माँगनी होगी। पुस्तकालय खुद उन्हें (उपयोगकर्ता की सहमति से, निश्चित रूप से) बनाएगा।

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

यदि कोई अपवाद होता है, तो रिकॉर्ड किए गए स्क्रीनशॉट OGG Theora कोडेक [5] द्वारा संपीड़ित होते हैं, और एक वीडियो फ़ाइल प्राप्त की जाती है जिसे क्रोम या फ़ायरफ़ॉक्स ब्राउज़र में या किसी भी वीडियो प्लेयर में खोला जा सकता है।

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

निष्कर्ष

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

वैसे, क्या आप जानते हैं कि C [6] में सबसे छोटा गिरने वाला कार्यक्रम कौन सा है?

main(){main();} 

संदर्भ

1. कर्क ग्लरम एट अल। डीबगिंग इन (वेरी) लार्ज: टेन इयर्स ऑफ़ इंप्लीमेंटेशन एंड एक्सपीरियंस। ऑपरेटिंग सिस्टम सिद्धांत (SOSP '09), 2009 पर 22 वें एसीएम संगोष्ठी की कार्यवाही।
2. विंडोज त्रुटि रिपोर्टिंग: प्रारंभ करना , MSDN
3. CrashRpt - विंडोज अनुप्रयोगों के लिए एक दुर्घटना रिपोर्टिंग प्रणाली। Google प्रोजेक्ट होस्टिंग।
4. ब्रेकपैड - क्रैश रिपोर्टिंग। Google प्रोजेक्ट होस्टिंग।
5. Theora वीडियो संपीड़न
6. सी , आरएसडीएन फ़ोरम में सबसे छोटा "गिरने" वाला कार्यक्रम