प्रोग्रामर और इंजीनियरों की लोककथाएँ (भाग 1)

यह इंटरनेट से कहानियों का एक चयन है कि कैसे बग कभी-कभी पूरी तरह से अविश्वसनीय अभिव्यक्तियाँ करते हैं। शायद आपके पास भी बताने को कुछ हो.

वेनिला आइसक्रीम से कार एलर्जी

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

यह दूसरी बार है जब मैं आपको लिख रहा हूं, और जवाब न देने के लिए मैं आपको दोषी नहीं ठहराता, क्योंकि यह पागलपन जैसा लगता है। हमारे परिवार में हर रात खाने के बाद आइसक्रीम खाने की परंपरा है। आइसक्रीम के प्रकार हर बार बदलते हैं, और रात के खाने के बाद पूरा परिवार चुनता है कि कौन सी आइसक्रीम खरीदनी है, जिसके बाद मैं दुकान पर जाता हूँ। मैंने हाल ही में एक नया पोंटियाक खरीदा है और तब से आइसक्रीम लेने के लिए मेरी यात्राएँ एक समस्या बन गई हैं। आप देखिए, हर बार जब मैं वेनिला आइसक्रीम खरीदता हूं और स्टोर से वापस आता हूं, तो कार स्टार्ट नहीं होती है। अगर मैं कोई और आइसक्रीम ले आऊं तो गाड़ी बिना किसी दिक्कत के चल जाती है. मैं एक गंभीर सवाल पूछना चाहता हूं, चाहे यह कितना भी बेवकूफी भरा लगे: "पोंटियाक में ऐसा क्या है कि जब मैं वेनिला आइसक्रीम लाता हूं तो यह शुरू नहीं होता है, लेकिन जब मैं आइसक्रीम का दूसरा स्वाद लाता हूं तो यह आसानी से शुरू हो जाता है?"

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

इंजीनियर तीन शाम और आया। पहली बार आइसक्रीम चॉकलेट थी। गाड़ी चल पड़ी. दूसरी बार स्ट्रॉबेरी आइसक्रीम थी. गाड़ी चल पड़ी. तीसरी शाम को उसने वेनिला लेने को कहा. कार स्टार्ट नहीं हुई.

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

इंजीनियर को जल्द ही एहसास हुआ कि कार के मालिक ने वेनिला आइसक्रीम खरीदने में कम समय बिताया। वजह थी स्टोर में सामान का लेआउट. वेनिला आइसक्रीम सबसे लोकप्रिय थी और इसे ढूंढना आसान बनाने के लिए इसे स्टोर के सामने एक अलग फ्रीजर में रखा गया था। और अन्य सभी किस्में स्टोर के पीछे थीं, और सही किस्म ढूंढने और भुगतान करने में बहुत अधिक समय लगा।

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

नैतिक: यहां तक ​​कि पूरी तरह से पागल समस्याएं भी कभी-कभी वास्तविक होती हैं।

कैश बैण्डीकूट

यह अनुभव करना दुखद है. एक प्रोग्रामर के रूप में, आपको पहले, दूसरे, तीसरे... अपने कोड को दोष देने की आदत होती है और दस हजारवें स्थान पर आप कंपाइलर को दोष देते हैं। और सूची में और भी नीचे आप पहले से ही उपकरण को दोष देते हैं।

यहाँ हार्डवेयर बग के बारे में मेरी कहानी है।

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

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

कुछ समय बाद, सोनी में हमारे निर्माता, कोनी बस, घबराने लगे। हम इस बग के साथ गेम को शिप नहीं कर सके, और छह सप्ताह बाद मुझे समझ नहीं आया कि समस्या का कारण क्या था। कोनी के माध्यम से, हमने अन्य PS1 डेवलपर्स से संपर्क किया: क्या किसी को भी कुछ इसी तरह का सामना करना पड़ा है? नहीं। मेमोरी कार्ड से किसी को कोई समस्या नहीं हुई।

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

लेकिन बात यह है कि किसी वीडियो गेम से कुछ हिस्सों को काटना बहुत मुश्किल है। यदि आपने गुरुत्वाकर्षण का अनुकरण करने वाला कोड हटा दिया है तो इसे कैसे चलाएं? या पात्र चित्रित कर रहे हैं?

इसलिए, हमें पूरे मॉड्यूल को स्टब्स से बदलना होगा जो कुछ उपयोगी करने का दिखावा करते हैं, लेकिन वास्तव में कुछ बहुत ही सरल करते हैं जिसमें त्रुटियां नहीं हो सकती हैं। हमें खेल के लिए कम से कम काम करने के लिए ऐसी बैसाखी लिखनी होगी। यह एक धीमी और दर्दनाक प्रक्रिया है.

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

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

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

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

यदि हमारे कोड में कोई चीज़ समय को भ्रमित कर दे तो क्या होगा? मैंने परीक्षण प्रोग्राम कोड में इससे संबंधित सभी चीजों की जांच की और देखा कि हमने प्रोग्राम करने योग्य टाइमर को PS1 से 1 kHz (प्रति सेकंड 1000 टिक) पर सेट किया है। यह काफ़ी है; डिफ़ॉल्ट रूप से, जब कंसोल प्रारंभ होता है, तो यह 100 Hz पर चलता है। और अधिकांश गेम इस आवृत्ति का उपयोग करते हैं।

गेम डेवलपर एंडी ने टाइमर को 1 kHz पर सेट किया ताकि गतिविधियों की गणना अधिक सटीक रूप से की जा सके। एंडी अति करने की प्रवृत्ति रखता है, और यदि हम गुरुत्वाकर्षण का अनुकरण करते हैं, तो हम इसे यथासंभव सटीकता से करते हैं!

लेकिन क्या होगा अगर टाइमर को तेज़ करने से प्रोग्राम की समग्र टाइमिंग प्रभावित हो, और इसलिए वह घड़ी जो मेमोरी कार्ड के लिए बॉड दर को नियंत्रित करती है?

मैंने टाइमर कोड पर टिप्पणी की। त्रुटि दोबारा नहीं हुई. लेकिन इसका मतलब यह नहीं है कि हमने इसे ठीक कर दिया, क्योंकि विफलता यादृच्छिक रूप से हुई। अगर मैं भाग्यशाली होता तो क्या होता?

कुछ दिनों बाद मैंने परीक्षण कार्यक्रम के साथ फिर से प्रयोग किया। बग दोबारा नहीं आया. मैं पूर्ण गेम कोडबेस पर वापस गया और सेव और लोड कोड को संशोधित किया ताकि प्रोग्रामयोग्य टाइमर मेमोरी कार्ड तक पहुंचने से पहले अपने मूल मूल्य (100 हर्ट्ज) पर रीसेट हो जाए, और फिर 1kHz पर रीसेट हो जाए। कोई और दुर्घटना नहीं हुई.

लेकिन ऐसा क्यों हुआ?

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

जब मुझे एहसास हुआ कि ये दोनों घटनाएँ आपस में जुड़ी हुई हैं, तो मैं आसानी से त्रुटि को पुन: उत्पन्न करने में सक्षम हो गया: मैंने मेमोरी कार्ड में रिकॉर्डिंग शुरू कर दी, नियंत्रक को स्थानांतरित कर दिया और मेमोरी कार्ड को बर्बाद कर दिया। मुझे यह एक हार्डवेयर बग जैसा लग रहा था।

मैं कोनी के पास आया और उसे अपनी खोज के बारे में बताया। उसने PS1 को डिज़ाइन करने वाले इंजीनियरों में से एक को जानकारी दी। "असंभव," उन्होंने उत्तर दिया, "यह कोई हार्डवेयर समस्या नहीं हो सकती।" मैंने कोनी से हमारे लिए बातचीत की व्यवस्था करने के लिए कहा।

इंजीनियर ने मुझे बुलाया और हमने उसकी टूटी-फूटी अंग्रेजी और मेरी (बेहद) टूटी-फूटी जापानी भाषा में बहस की। अंत में मैंने कहा, "मुझे अपना 30 लाइन का परीक्षण प्रोग्राम भेजने दीजिए जहां नियंत्रक को हिलाने से बग उत्पन्न होता है।" वह मान गया। कहा कि यह समय की बर्बादी थी और वह एक नए प्रोजेक्ट पर काम करने में बहुत व्यस्त थे, लेकिन हम हार मान लेंगे क्योंकि हम सोनी के लिए एक बहुत ही महत्वपूर्ण डेवलपर थे। मैंने अपना परीक्षण कार्यक्रम साफ़ किया और उसे भेज दिया।

अगली शाम (हम लॉस एंजिल्स में थे और वह टोक्यो में था) उसने मुझे फोन किया और संकोचपूर्वक माफ़ी मांगी। यह एक हार्डवेयर समस्या थी.

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

लेकिन लब्बोलुआब यह है कि मदरबोर्ड पर घटकों के बीच हस्तक्षेप था। और जब 1 किलोहर्ट्ज़ पर चलने वाले टाइमर के साथ नियंत्रक पोर्ट और मेमोरी कार्ड पोर्ट के माध्यम से एक साथ डेटा संचारित किया जाता है, तो बिट्स खो जाते हैं, डेटा खो जाता है, और कार्ड क्षतिग्रस्त हो जाता है।

बुरी गायें

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

सबसे पहले, उन्होंने सभी अस्पष्टीकृत झरनों के आँकड़े एकत्र किए और तिथि और समय के अनुसार एक ग्राफ बनाया। पैटर्न स्पष्ट था. कुछ और दिनों तक निरीक्षण करने के बाद, सर्गेई को एहसास हुआ कि वह भविष्य में सिस्टम विफलताओं के समय की आसानी से भविष्यवाणी कर सकता है।

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

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

मवेशियों ने न केवल बहुत अधिक विकिरण उत्सर्जित किया, बल्कि इसका स्तर इतना अधिक था कि इससे एसएम-1800 की मेमोरी में बिट्स की यादृच्छिक क्षति हुई, जो स्टेशन के बगल की एक इमारत में स्थित थी।

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

पाइपों के माध्यम से

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

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

इसलिए, यह आश्चर्य की बात नहीं है कि इस व्यस्त समय के दौरान, जेम्स सुबह कार्यालय पहुंचे, और इससे पहले कि वह अपनी मेज पर पहुंच पाते, प्रबंधक ने सामान्य से अधिक कैफीन से भरपूर उनका स्वागत किया।

"मुझे डर है कि आपको जल्द से जल्द एनापोलिस, नोवा स्कोटिया जाने की ज़रूरत है।" उनका पूरा सिस्टम ख़राब हो गया, और उनके इंजीनियरों के साथ एक रात काम करने के बाद, हम यह पता नहीं लगा सके कि क्या हुआ। ऐसा लगता है कि सर्वर पर नेटवर्क फेल हो गया है. लेकिन सिस्टम कई मिनटों तक चालू रहने के बाद ही।

— वे पुरानी व्यवस्था में नहीं लौटे? - जेम्स ने पूरी गंभीरता से उत्तर दिया, हालाँकि मानसिक रूप से उसने आश्चर्य से अपनी आँखें चौड़ी कर लीं।

- बिल्कुल: उनके आईटी विशेषज्ञ ने "प्राथमिकताएं बदल दीं" और अपने पुराने सर्वर के साथ जाने का फैसला किया। जेम्स, उन्होंने छह साइटों पर सिस्टम स्थापित किया और केवल प्रीमियम समर्थन के लिए भुगतान किया, और उनका व्यवसाय अब उसी तरह चल रहा है जैसे 1950 के दशक में चलता था।

जेम्स थोड़ा सीधा हो गया।

- वह दूसरी बात है. ठीक है, चलिए शुरू करते हैं।

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

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

सिनेमाघर का पार्श्व प्रवेश द्वार एक सुनसान गली में था। जेम्स दरवाजे तक गया और दस्तक दी। जल्द ही यह चरमराया और थोड़ा खुल गया।

-क्या आप सफ़ाईकर्मी हैं? - अंदर से कर्कश आवाज आई।

- हाँ, यह मैं हूँ... मैं सब कुछ ठीक करने आया हूँ।

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

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

जेम्स ने मार्क को फोन किया और उसे स्थिति की जानकारी दी। यह कल्पना करना कठिन नहीं है कि जेम्स यहीं रुकना चाहता होगा और देखना चाहेगा कि क्या कुछ अप्रत्याशित घटित होता है। वह सीढ़ियों से नीचे गया और कर्मचारियों से पूछने लगा कि क्या हुआ। जाहिर है सिस्टम ने काम करना बंद कर दिया है. उन्होंने इसे बंद और चालू किया, सब कुछ काम करता रहा। लेकिन 10 मिनट बाद ही सिस्टम बंद हो गया।

ठीक इसी वक्त कुछ ऐसा ही हुआ. अचानक, टिकटिंग प्रणाली में त्रुटियाँ आने लगीं। कर्मचारियों ने आह भरी और कागज़ के टिकट ले लिए, और जेम्स सर्वर रूम में तेजी से चला गया। सर्वर के साथ सब कुछ अच्छा लग रहा था।

तभी एक कर्मचारी अंदर आया.

- सिस्टम फिर से काम कर रहा है।

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

- सिस्टम ख़राब है.

जेम्स ने सर्वर पर नज़र डाली। स्क्रीन पर बहुरंगी आकृतियों का एक दिलचस्प और परिचित पैटर्न नाच रहा था - बेतरतीब ढंग से सिकुड़ते और आपस में जुड़ते पाइप। हम सभी ने कभी न कभी यह स्क्रीनसेवर देखा है। यह खूबसूरती से प्रस्तुत किया गया था और सचमुच सम्मोहित कर देने वाला था।

जेम्स ने एक बटन दबाया और पैटर्न गायब हो गया। वह जल्दी से टिकट कार्यालय पहुंचा और रास्ते में उसकी मुलाकात एक कर्मचारी से हुई जो उसके पास लौट रहा था।

- सिस्टम फिर से काम कर रहा है।

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

जेम्स सर्वर रूम में लौटा, लॉग इन किया और स्क्रीनसेवर को खूबसूरत पाइपों से बदलकर एक खाली स्क्रीन बना दी। यानी, 100% प्रोसेसर संसाधनों का उपभोग करने वाले स्क्रीनसेवर के बजाय, मैंने एक और स्थापित किया जो संसाधनों का उपभोग नहीं करता है। फिर मैंने अपना अनुमान जांचने के लिए 10 मिनट तक इंतजार किया।

जब जेम्स अगले सिनेमाघर में पहुंचे, तो वह सोच रहे थे कि अपने मैनेजर को कैसे समझाएं कि उन्होंने स्क्रीन सेवर बंद करने के लिए अभी-अभी 800 किमी की उड़ान भरी है।

चंद्रमा के एक निश्चित चरण के दौरान दुर्घटना

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

पहला पेपर संस्करण शब्दजाल फ़ाइल (स्टील-1983) में ऐसी लाइन का एक उदाहरण था जिसके कारण वर्णित बग आया, लेकिन टाइपसेटर ने इसे "ठीक" कर दिया। तब से इसे "चंद्रमा चरण बग" के रूप में वर्णित किया गया है।

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

टॉयलेट में फ्लश करने से ट्रेन रुक जाती है

सबसे बढ़िया हार्डवेयर बग जिसके बारे में मैंने कभी सुना है वह फ़्रांस की हाई स्पीड ट्रेन में था। बग के कारण ट्रेन को आपातकालीन ब्रेक लगाना पड़ा, लेकिन केवल तभी जब ट्रेन में यात्री मौजूद थे। ऐसे प्रत्येक मामले में, ट्रेन को सेवा से बाहर कर दिया गया, जाँच की गई, लेकिन कुछ भी नहीं मिला। फिर उसे लाइन पर वापस भेज दिया गया और वह तुरंत रुक गया।

एक जांच के दौरान ट्रेन में यात्रा कर रहा एक इंजीनियर शौचालय चला गया। वह जल्द ही बह गया, बूम! आपातकालीन बंद।

इंजीनियर ने ड्राइवर से संपर्क किया और पूछा:

- ब्रेक लगाने से ठीक पहले आप क्या कर रहे थे?

- ठीक है, मैं नीचे उतरते समय धीमा हो गया...

यह अजीब था, क्योंकि सामान्य परिचालन के दौरान ट्रेन उतरते समय दर्जनों बार धीमी हो जाती थी। ट्रेन आगे बढ़ी, और अगले उतरने पर ड्राइवर ने चेतावनी दी:

- मैं धीमा करने जा रहा हूँ।

कुछ नहीं हुआ।

- आखिरी बार ब्रेक लगाने के दौरान आपने क्या किया? - ड्राइवर से पूछा।

- अच्छा... मैं शौचालय में था...

- ठीक है, फिर शौचालय जाओ और वही करो जो तुमने तब किया था जब हम दोबारा नीचे जाएंगे!

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

अब वे समस्या को पुन: उत्पन्न कर सकते थे और उन्हें इसका कारण ढूंढने की आवश्यकता थी।

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

वह प्रवेश द्वार जो फोरट्रान से नफरत करता था

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

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

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

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

कठिन समय

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

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

पहले, Apple मूल तिथि के बाद से सेकंड की संख्या को संग्रहीत करने के लिए 32 बिट्स का उपयोग करता था। एक बिट दो मानों में से एक को संग्रहीत कर सकता है - 1 या 0। दो बिट चार मानों में से एक को संग्रहीत कर सकते हैं: 00, 01, 10, 11। तीन बिट - आठ में से एक मान को संग्रहीत कर सकते हैं: 000, 001, 010, 011, 100 , 101, 110, 111, आदि। और 32 232 मानों में से एक, यानी 4 सेकंड संग्रहीत कर सकता है। Apple की तारीखों के लिए, यह लगभग 294 वर्षों के बराबर है, इसलिए पुराने Mac 967 के बाद की तारीखों को संभाल नहीं सकते हैं। और यदि सिस्टम बैटरी खत्म हो जाती है, तो युग की शुरुआत से तारीख 296 सेकंड पर रीसेट हो जाती है, और आपको हर बार कंप्यूटर चालू करने पर (या जब तक आप नई बैटरी नहीं खरीदते हैं) मैन्युअल रूप से तारीख निर्धारित करनी होगी।

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

आगे बढ़ो। हमने आईबीएम के "किलर एप्लिकेशन" लोटस 1-2-3 का उपयोग किया, जिसने पीसी क्रांति शुरू करने में मदद की, हालांकि ऐप्पल कंप्यूटर में विसीकैल्क था, जिसने पर्सनल कंप्यूटर को सफल बनाया। निष्पक्षता में, यदि 1-2-3 प्रकट नहीं हुआ होता, तो पीसी शायद ही आगे बढ़ते, और पर्सनल कंप्यूटर का इतिहास बहुत अलग तरीके से विकसित हो सकता था। लोटस 1-2-3 ने गलती से 1900 को लीप वर्ष मान लिया। जब माइक्रोसॉफ्ट ने अपनी पहली स्प्रेडशीट, मल्टीप्लान जारी की, तो उसने बाजार के एक छोटे हिस्से पर कब्जा कर लिया। और जब उन्होंने एक्सेल प्रोजेक्ट लॉन्च किया, तो उन्होंने न केवल लोटस 1-2-3 से पंक्ति और स्तंभ नामकरण योजना की नकल करने का फैसला किया, बल्कि जानबूझकर 1900 को एक लीप वर्ष मानकर बग संगतता सुनिश्चित करने का भी फैसला किया। यह समस्या आज भी मौजूद है. अर्थात्, 1-2-3 में यह एक बग था, लेकिन एक्सेल में यह एक सचेत निर्णय था जिसने यह सुनिश्चित किया कि सभी 1-2-3 उपयोगकर्ता डेटा को बदले बिना एक्सेल में अपनी तालिकाएँ आयात कर सकते हैं, भले ही वह गलत हो।

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

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

एक्सेल में, दिनांक 5 जुलाई, 1998 को "07-05-98" (बेकार अमेरिकी प्रणाली), "जुलाई 5, 98", "5 जुलाई, 1998", "5-जुलाई-98" या प्रारूप में दर्शाया जा सकता है। कुछ अन्य प्रारूप। एक और बेकार प्रारूप (विडंबना यह है कि Excel के मेरे संस्करण द्वारा प्रस्तुत प्रारूपों में से एक ISO 8601 था)। हालाँकि, तालिका के भीतर, बिना स्वरूपित तारीख को युग-35981 के लिए "1900" या युग-34519 के लिए "1904" के रूप में संग्रहीत किया गया था (संख्याएँ युग के बाद से दिनों की संख्या का प्रतिनिधित्व करती हैं)। मैंने स्वरूपित तिथि से वर्ष निकालने के लिए बस एक साधारण पार्सर का उपयोग किया, और फिर बिना स्वरूपित दिनांक से वर्ष निकालने के लिए एक्सेल पार्सर का उपयोग किया। यदि दोनों मानों में 4 वर्ष का अंतर होता, तो मुझे पता होता कि मैं युग-1904 वाले सिस्टम का उपयोग कर रहा था।

मैंने स्वरूपित तिथियों का उपयोग क्यों नहीं किया? क्योंकि 5 जुलाई 1998 को खोए हुए महीने के दिन के साथ "जुलाई, 98" के रूप में स्वरूपित किया जा सकता है। हमें इतनी सारी कंपनियों से तालिकाएँ प्राप्त हुईं जिन्होंने उन्हें इतने अलग-अलग तरीकों से बनाया कि तारीखों का पता लगाना हमारे (इस मामले में, मेरे) ऊपर था। इसके अलावा, यदि एक्सेल इसे सही करता है, तो हमें भी ऐसा ही करना चाहिए!

उसी समय मेरा सामना 39082 से हुआ। मैं आपको याद दिला दूं कि लोटस 1-2-3 ने 1900 को एक लीप वर्ष माना था, और इसे एक्सेल में ईमानदारी से दोहराया गया था। और चूँकि इसने वर्ष 1900 में एक दिन जोड़ दिया, उसी दिन के लिए कई तिथि गणना कार्य गलत हो सकते हैं। यानी, 39082 1 जनवरी, 2011 (मैक पर) या 31 दिसंबर, 2006 (विंडोज़ पर) हो सकता था। यदि मेरे "वर्ष पार्सर" ने स्वरूपित मान से वर्ष 2011 निकाला है, तो सब कुछ ठीक है। लेकिन चूंकि एक्सेल पार्सर को यह पता नहीं है कि किस युग का उपयोग किया जा रहा है, यह डिफ़ॉल्ट रूप से युग-1900 पर आ जाता है और वर्ष 2006 लौटा देता है। मेरे एप्लिकेशन ने देखा कि अंतर 5 साल का था, इसे एक त्रुटि माना, इसे लॉग किया, और एक बिना स्वरूपित मान लौटाया।

इससे निजात पाने के लिए, मैंने यह लिखा (छद्म कोड):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

और फिर सभी 40 तिथियों को सही ढंग से पार्स किया गया।

बड़े मुद्रण कार्यों के बीच में

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

उन्होंने ड्राइव को फिर से डिज़ाइन किया ताकि उनमें एक केंद्रीय "ए" ड्राइव सात "बी" ड्राइव से जुड़ी हो सके, और रैम में छोटा ओएस जो "ए" ड्राइव को नियंत्रित करता है वह सभी "बी" ड्राइव को पढ़ने और लिखने के संचालन को सौंप सकता है।

हर बार जब ड्राइव "ए" शुरू किया गया था, तो ऑपरेटिंग सिस्टम को इसकी मेमोरी में लोड करने के लिए "ए" से जुड़े परिधीय ड्राइव में एक फ्लॉपी डिस्क डालना आवश्यक था। यह अत्यंत आदिम था: कंप्यूटिंग शक्ति 8-बिट माइक्रोकंट्रोलर द्वारा प्रदान की गई थी।

ऐसे उपकरणों के लिए लक्षित दर्शक बहुत बड़े डेटा वेयरहाउस वाली कंपनियां थीं - बैंक, खुदरा श्रृंखलाएं, आदि - जिन्हें बहुत सारे एड्रेस लेबल या बैंक स्टेटमेंट प्रिंट करने की आवश्यकता होती थी।

एक ग्राहक को एक समस्या थी. प्रिंट कार्य के बीच में, एक विशेष ड्राइव "ए" काम करना बंद कर सकता है, जिससे पूरा काम रुक सकता है। ड्राइव के संचालन को बहाल करने के लिए, कर्मचारियों को सब कुछ रीबूट करना पड़ा। और यदि यह छह घंटे के कार्य के बीच में हुआ, तो भारी मात्रा में महंगा कंप्यूटर समय बर्बाद हो गया और पूरे ऑपरेशन का शेड्यूल बाधित हो गया।

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

फिर तकनीशियनों ने मुख्यालय फोन किया और विशेषज्ञ को बुलाया।

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

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

तीसरी विफलता तक, विशेषज्ञ ने कुछ देखा। विफलता तब हुई जब कर्मियों ने एक विदेशी ड्राइव में टेप बदले। इसके अलावा, जैसे ही कर्मचारियों में से एक फर्श पर एक निश्चित टाइल के माध्यम से चला गया, विफलता हुई।

ऊंचा फर्श 6 से 8 इंच की ऊंचाई पर बिछाई गई एल्यूमीनियम टाइलों से बना था। किसी भी व्यक्ति का पैर गलती से किसी महत्वपूर्ण केबल पर न पड़ जाए, इसके लिए कंप्यूटर के कई तार ऊंचे फर्श के नीचे से गुजर रहे थे। ऊंचे फर्श के नीचे मलबा आने से रोकने के लिए टाइलें बहुत कसकर बिछाई गई थीं।

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

आज, रैम रेडियो फ्रीक्वेंसी हस्तक्षेप से काफी बेहतर सुरक्षित है। लेकिन उन सालों में ऐसा नहीं था. विशेषज्ञ को एहसास हुआ कि इस हस्तक्षेप ने मेमोरी और इसके साथ ऑपरेटिंग सिस्टम के संचालन को बाधित कर दिया। उन्होंने सहायता सेवा को बुलाया, नई टाइलें मंगवाईं, उन्हें स्वयं स्थापित किया और समस्या गायब हो गई।

यह उच्च ज्वार है!

यह कहानी पोर्ट्समाउथ (मुझे लगता है) में एक कार्यालय की चौथी या पांचवीं मंजिल पर, डॉक क्षेत्र में, एक सर्वर रूम में हुई थी।

एक दिन मुख्य डेटाबेस वाला यूनिक्स सर्वर क्रैश हो गया। उन्होंने उसे रिबूट किया, लेकिन वह खुशी-खुशी बार-बार गिरता रहा। हमने सहायता सेवा से किसी को कॉल करने का निर्णय लिया।

सहायता करने वाला व्यक्ति... मुझे लगता है कि उसका नाम मार्क था, लेकिन इससे कोई फर्क नहीं पड़ता... मुझे नहीं लगता कि मैं उसे जानता हूं। वास्तव में इससे कोई फर्क नहीं पड़ता। आइए मार्क के साथ बने रहें, ठीक है? महान।

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

उसी शाम सर्वर फिर से क्रैश हो गया। कहानी वही है... सर्वर नहीं उठता. मार्क दूर से मदद करने की कोशिश करता है, लेकिन क्लाइंट सर्वर शुरू नहीं कर पाता।

एक और ट्रेन, बस, नींबू मेरिंग्यू या कुछ अन्य बकवास, और मार्क पोर्ट्समाउथ में वापस आ गया है। देखिए, सर्वर बिना किसी समस्या के बूट होता है! चमत्कार। मार्क यह जांचने में कई घंटे बिताता है कि ऑपरेटिंग सिस्टम या सॉफ़्टवेयर के साथ सब कुछ ठीक है और लीड्स के लिए प्रस्थान करता है।

दिन के मध्य में सर्वर क्रैश हो जाता है (इसे आसान बनाएं!)। इस बार सर्वर को बदलने के लिए हार्डवेयर सपोर्ट वाले लोगों को लाना उचित लगता है। लेकिन नहीं, करीब 10 घंटे बाद ये भी गिर जाता है.

स्थिति कई दिनों तक दोहराई गई। सर्वर काम करता है, लगभग 10 घंटों के बाद क्रैश हो जाता है और अगले 2 घंटों तक शुरू नहीं होता है। उन्होंने कूलिंग, मेमोरी लीक की जाँच की, उन्होंने सब कुछ जाँचा, लेकिन कुछ नहीं मिला। फिर दुर्घटनाएं रुक गईं.

हफ्ता बेफिक्री से गुजरा... सब खुश थे। जब तक यह सब फिर से शुरू न हो जाए तब तक खुश हूं। तस्वीर वही है. 10 घंटे काम, 2-3 घंटे डाउनटाइम...

और फिर किसी ने (मुझे लगता है कि उन्होंने मुझसे कहा था कि इस व्यक्ति का आईटी से कोई लेना-देना नहीं है) ने कहा:

"यह ज्वार है!"

विस्मयादिबोधक का उत्तर खाली निगाहों से दिया गया, और किसी का हाथ शायद सुरक्षा कॉल बटन पर झिझक रहा था।

"यह ज्वार के साथ काम करना बंद कर देता है।"

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

"पिछले सप्ताह ज्वार कम था, लेकिन इस सप्ताह यह अधिक है।"

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

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

रॉकेट के लिए उड़ान मिशन

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

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

और थैंक्सगिविंग से पहले शुक्रवार को फोन की घंटी बजी।

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

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

और सिस्टम को पोर्ट करने वाले व्यक्ति के रूप में मुझ पर ध्यान दिया गया।

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

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

चूँकि पत्रिकाओं में कुछ भी दिलचस्प नहीं था, इसलिए हमने स्थानीय प्रयोगशाला में समस्या को पुन: पेश करने का प्रयास करने का निर्णय लिया। यह कोई आसान काम नहीं था क्योंकि यह घटना प्रति 1000 रन पर लगभग एक बार होती थी। एक संदिग्ध कारण यह था कि विक्रेता द्वारा विकसित म्यूटेक्स फ़ंक्शन (VADS माइग्रेशन पैकेज का हिस्सा) के लिए कॉल Unlock अनलॉकिंग नहीं हुई. प्रोसेसिंग थ्रेड जिसे फ़ंक्शन कहा जाता है, दिल की धड़कन संदेशों को संसाधित करता है, जो नाममात्र रूप से हर सेकंड आता है। हमने आवृत्ति को 10 हर्ट्ज तक बढ़ा दिया, यानी प्रति सेकंड 10 बार, और दौड़ना शुरू कर दिया। करीब एक घंटे बाद सिस्टम लॉक हो गया। लॉग में, हमने देखा कि रिकॉर्ड किए गए संदेशों का क्रम वही था जो असफल परीक्षण के दौरान था। हमने कई और रन बनाए, शुरुआत के 45-90 मिनट बाद सिस्टम लगातार अवरुद्ध रहा, और हर बार लॉग में वही मार्ग शामिल था। भले ही हम तकनीकी रूप से अलग कोड चला रहे थे - संदेश आवृत्ति अलग थी - सिस्टम का व्यवहार समान था, इसलिए हमें विश्वास था कि यह लोड परिदृश्य समान समस्या पैदा कर रहा था।

अब हमें यह पता लगाने की जरूरत है कि अभिव्यक्ति के क्रम में वास्तव में अवरोध कहां हुआ।

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

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

यह समझने के लिए कि कोड की कौन सी पंक्ति समस्या का कारण बन रही है, मुझे कार्य स्विच को ट्रिगर किए बिना कथनों के अनुक्रम के माध्यम से प्रगति को रिकॉर्ड करने का एक तरीका खोजने की आवश्यकता है, जो किसी दुर्घटना को होने से रोक सके। इसलिए मैं फायदा नहीं उठा सका Put_Line()I/O परिचालन करने से बचने के लिए। मैं एक काउंटर वैरिएबल या कुछ इसी तरह सेट कर सकता हूं, लेकिन अगर मैं इसे स्क्रीन पर प्रदर्शित नहीं कर सकता तो मैं इसका मूल्य कैसे देख सकता हूं?

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

अवरोधक अभिव्यक्ति का मूल्यांकन करने के लिए यह आवश्यक सुराग था।

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

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

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

मैंने ट्रैकिंग के साथ कोड चलाया। वह ठिठक गया. और निगरानी ने घड़ी की कल की तरह काम किया।

लॉग में अपेक्षित अनुक्रम था, जो एक मान से बाधित था जो दर्शाता था कि म्यूटेक्स को बुलाया गया था Unlock, और कार्य पूरा नहीं हुआ - जैसा कि पिछली हजारों कॉलों के मामले में हुआ है।

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

मुझे आवश्यक कोड के टुकड़े की सुरक्षा के लिए, मैंने उस टुकड़े तक म्यूटेक्स पहुंच को नियंत्रित करने के लिए म्यूटेक्स फ़ंक्शन कॉल (ओएस म्यूटेक्स कार्यक्षमता के शीर्ष पर निर्मित) को एक छोटे देशी एडा म्यूटेक्स पैकेज से बदल दिया।

मैंने इसे कोड में डाला और परीक्षण चलाया। सात घंटे बाद भी कोड काम कर रहा था।

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

यह मेरे करियर की सबसे भीड़भाड़ वाली कोड समीक्षा थी 🙂 मेरे साथ कमरे में लगभग दस इंजीनियर और प्रबंधक थे, अन्य दस लोग कॉन्फ्रेंस कॉल पर थे - और उन सभी ने कोड की लगभग 20 पंक्तियों की जांच की।

कोड की समीक्षा की गई, नई निष्पादन योग्य फ़ाइलें इकट्ठी की गईं और औपचारिक प्रतिगमन परीक्षण के लिए प्रस्तुत की गईं। कुछ हफ़्ते बाद, उलटी गिनती परीक्षण सफल रहा और रॉकेट ने उड़ान भरी।

ठीक है, यह सब ठीक है और अच्छा है, लेकिन कहानी का मतलब क्या है?

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

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

मैं समस्या की प्रकृति को समझ गया। मुझे बिल्कुल नहीं पता था कि यह कहां हो रहा था या क्यों हो रहा था, लेकिन मैं जानता था कि क्या हो रहा था।

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

कोड के साथ संघर्ष की ऐसी कहानियाँ उन लोगों के लिए बहुत दिलचस्प नहीं हैं जो इस तरह के संघर्ष की विशेषताओं और स्थितियों से परिचित नहीं हैं। लेकिन ये कहानियाँ हमें यह समझने में मदद करती हैं कि वास्तव में कठिन समस्याओं को हल करने के लिए क्या करना पड़ता है।

वास्तव में कठिन समस्याओं को हल करने के लिए, आपको केवल एक प्रोग्रामर से अधिक बनने की आवश्यकता है। आपको कोड के "भाग्य" को समझने की आवश्यकता है, यह अपने पर्यावरण के साथ कैसे इंटरैक्ट करता है, और पर्यावरण स्वयं कैसे काम करता है।

और फिर आपका अपना बर्बाद छुट्टी वाला सप्ताह होगा।

को जारी रखा जाएगा.

स्रोत: www.habr.com