प्रोग्रामर आणि इंजिनिअर्सची लोककथा (भाग 1)

बग्समध्ये कधीकधी पूर्णपणे अविश्वसनीय प्रकटीकरण कसे होते याबद्दल इंटरनेटवरील कथांची ही निवड आहे. कदाचित तुम्हालाही काही सांगायचे असेल.

व्हॅनिला आइस्क्रीमची कार ऍलर्जी

अभियंत्यांसाठी एक कथा ज्यांना हे समजते की स्पष्ट हे नेहमीच उत्तर नसते आणि तथ्ये कितीही दूरगामी वाटली तरीही ते तथ्य आहेत. जनरल मोटर्स कॉर्पोरेशनच्या पॉन्टियाक विभागाकडे तक्रार प्राप्त झाली:

ही दुसरी वेळ आहे मी तुला लिहित आहे, आणि उत्तर न दिल्याबद्दल मी तुला दोष देत नाही, कारण ते वेडे वाटते. आमच्या कुटुंबात रोज रात्री जेवणानंतर आईस्क्रीम खाण्याची परंपरा आहे. आईस्क्रीमचे प्रकार प्रत्येक वेळी बदलतात आणि रात्रीच्या जेवणानंतर संपूर्ण कुटुंब कोणते आईस्क्रीम घ्यायचे ते निवडते, त्यानंतर मी दुकानात जातो. मी अलीकडे एक नवीन Pontiac विकत घेतले आणि तेव्हापासून आईस्क्रीम मिळविण्यासाठी माझ्या सहली एक समस्या बनल्या आहेत. तुम्ही पहा, प्रत्येक वेळी मी व्हॅनिला आइस्क्रीम विकत घेतो आणि दुकानातून परत येतो तेव्हा कार सुरू होत नाही. मी दुसरे कुठलेही आईस्क्रीम आणले तर कोणतीही अडचण न होता गाडी सुरू होते. मला एक गंभीर प्रश्न विचारायचा आहे, तो कितीही मूर्खपणाचा वाटत असला तरीही: "पॉन्टियाकमध्ये असे काय आहे की मी व्हॅनिला आइस्क्रीम आणतो तेव्हा ते सुरू होत नाही, परंतु जेव्हा मी आइस्क्रीमची दुसरी चव आणतो तेव्हा ते सहज सुरू होते?"

आपण कल्पना करू शकता की, विभाग अध्यक्ष पत्र बद्दल साशंक होते. तथापि, फक्त बाबतीत, मी तपासण्यासाठी अभियंता पाठवला. एका सुंदर परिसरात राहणारा श्रीमंत, सुशिक्षित माणूस भेटला याचे त्याला आश्चर्य वाटले. रात्रीच्या जेवणानंतर लगेच भेटण्याचे त्यांनी मान्य केले जेणेकरून ते दोघे आईस्क्रीमसाठी दुकानात जाऊ शकतील. ती संध्याकाळ व्हॅनिला होती, आणि जेव्हा ते कारकडे परत आले तेव्हा ती सुरू होणार नव्हती.

अजून तीन संध्याकाळी इंजिनियर आले. पहिल्यांदा आईस्क्रीम चॉकलेट होते. गाडी सुरू झाली. दुस-यांदा स्ट्रॉबेरी आईस्क्रीम होते. गाडी सुरू झाली. तिसऱ्या संध्याकाळी त्याने व्हॅनिला घेण्यास सांगितले. गाडी सुरू झाली नाही.

तर्कसंगतपणे, इंजिनियरने कारला व्हॅनिला आइस्क्रीमची ऍलर्जी आहे यावर विश्वास ठेवण्यास नकार दिला. म्हणून, मी कारच्या मालकाशी सहमत झालो की जोपर्यंत त्याला समस्येचे निराकरण होत नाही तोपर्यंत तो त्याच्या भेटी चालू ठेवेल. आणि वाटेत, त्याने नोट्स घेण्यास सुरुवात केली: त्याने सर्व माहिती, दिवसाची वेळ, गॅसोलीनचा प्रकार, दुकानातून येण्याची आणि परत येण्याची वेळ इत्यादी लिहून ठेवल्या.

इंजिनियरला लवकरच समजले की कारच्या मालकाने व्हॅनिला आइस्क्रीम खरेदी करण्यात कमी वेळ घालवला. कारण होते स्टोअरमधील वस्तूंचे लेआउट. व्हॅनिला आइस्क्रीम हे सर्वात लोकप्रिय होते आणि ते शोधणे सोपे करण्यासाठी स्टोअरच्या समोर वेगळ्या फ्रीजरमध्ये ठेवले होते. आणि इतर सर्व वाण स्टोअरच्या मागील बाजूस होते आणि योग्य विविधता शोधण्यात आणि पैसे देण्यास जास्त वेळ लागला.

आता प्रश्न अभियंत्यासाठी होता: जर इंजिन बंद झाल्यापासून कमी वेळ गेला असेल तर कार सुरू का झाली नाही? समस्या व्हॅनिला आइस्क्रीमची नसून वेळेची असल्याने, अभियंत्यांना पटकन उत्तर सापडले: ते गॅस लॉक होते. हे दररोज संध्याकाळी होते, परंतु जेव्हा कार मालकाने आइस्क्रीम शोधण्यात अधिक वेळ घालवला तेव्हा इंजिन पुरेसे थंड होऊ शकले आणि सहज सुरू झाले. आणि जेव्हा त्या माणसाने व्हॅनिला आइस्क्रीम विकत घेतला तेव्हा इंजिन अजूनही खूप गरम होते आणि गॅस लॉक विरघळायला वेळ नव्हता.

नैतिक: अगदी विलक्षण समस्या देखील कधीकधी वास्तविक असतात.

क्रॅश मांजराएवढी मोठी घूस

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

हार्डवेअर बगबद्दल माझी कथा येथे आहे.

Crash Bandicoot या गेमसाठी, मी मेमरी कार्ड लोड करण्यासाठी आणि सेव्ह करण्यासाठी कोड लिहिला. अशा स्मग गेम डेव्हलपरसाठी, हे उद्यानात फिरण्यासारखे होते: मला वाटले की कामाला बरेच दिवस लागतील. तथापि, मी सहा आठवड्यांसाठी कोड डीबग करणे समाप्त केले. वाटेत, मी इतर समस्या सोडवल्या, परंतु दर काही दिवसांनी मी काही तासांसाठी या कोडवर परतलो. यातना होती.

लक्षण असे दिसले: जेव्हा तुम्ही गेमचा सध्याचा प्लेथ्रू सेव्ह करता आणि मेमरी कार्ड ऍक्सेस करता तेव्हा सर्वकाही जवळजवळ नेहमीच ठीक होते... परंतु काहीवेळा कोणत्याही स्पष्ट कारणाशिवाय वाचन किंवा लेखन ऑपरेशन कालबाह्य होते. लहान रेकॉर्डिंग अनेकदा मेमरी कार्ड खराब करते. जेव्हा एखादा खेळाडू वाचवण्याचा प्रयत्न करतो तेव्हा तो केवळ जतन करण्यात अयशस्वी होत नाही तर नकाशा नष्ट करतो. बकवास.

थोड्या वेळाने, आमचा सोनी येथील निर्माता कोनी बस घाबरू लागला. आम्ही या बगसह गेम पाठवू शकलो नाही आणि सहा आठवड्यांनंतर मला समजले नाही की समस्या कशामुळे आहे. कॉनी द्वारे, आम्ही इतर PS1 विकसकांशी संपर्क साधला: कोणालाही असे काही आढळले आहे का? नाही. मेमरी कार्डमध्ये कोणालाच समस्या नव्हती.

तुमच्याकडे डीबगिंगसाठी कोणतीही कल्पना नसताना, "विभाजित करा आणि जिंकणे" हा एकमेव दृष्टीकोन उरतो: दोषपूर्ण प्रोग्राममधून अधिक आणि अधिक कोड काढून टाका जोपर्यंत तुलनेने लहान तुकडा शिल्लक राहत नाही ज्यामुळे समस्या उद्भवते. म्हणजेच, बग असलेला भाग शिल्लक राहेपर्यंत तुम्ही प्रोग्राम तुकडा तुकडा कापला.

पण गोष्ट अशी आहे की व्हिडिओ गेममधून भाग काढणे खूप कठीण आहे. गुरुत्वाकर्षणाचे अनुकरण करणारा कोड तुम्ही काढून टाकला तर ते कसे चालवायचे? किंवा वर्ण रेखाटणे?

म्हणून, आम्हाला संपूर्ण मॉड्यूल्स अशा स्टब्ससह पुनर्स्थित करावे लागतील जे काहीतरी उपयुक्त असल्याचे भासवत आहेत, परंतु प्रत्यक्षात काहीतरी सोपे आहे ज्यामध्ये त्रुटी असू शकत नाहीत. किमान चालण्यासाठी खेळासाठी असे क्रॅच लिहावे लागतील. ही एक मंद आणि वेदनादायक प्रक्रिया आहे.

थोडक्यात, मी ते केले. गेम चालवण्यासाठी सिस्टीम कॉन्फिगर करणारा, रेंडरिंग हार्डवेअर इ. सुरू करणारा प्रारंभिक कोड माझ्याकडे शिल्लक राहिल्याशिवाय मी कोडचे अधिकाधिक तुकडे काढून टाकले. अर्थात, या टप्प्यावर मी सेव्ह आणि लोड मेनू तयार करू शकलो नाही, कारण मला सर्व ग्राफिक्स कोडसाठी स्टब तयार करावा लागेल. परंतु मी (अदृश्य) सेव्ह आणि लोड स्क्रीन वापरून वापरकर्ता असल्याचे भासवू शकतो आणि सेव्ह करण्यास सांगू शकतो आणि नंतर मेमरी कार्डवर लिहू शकतो.

यामुळे मला कोडचा एक छोटासा तुकडा मिळाला ज्यामध्ये वरील समस्या अजूनही होती - परंतु तरीही ते यादृच्छिकपणे घडत होते! बर्‍याचदा सर्व काही ठीक चालले, परंतु अधूनमधून त्रुटी आल्या. मी जवळजवळ सर्व गेम कोड काढले, परंतु बग अजूनही जिवंत होता. हे गोंधळात टाकणारे होते: उर्वरित कोडने प्रत्यक्षात काहीही केले नाही.

कधीतरी, बहुधा पहाटे तीनच्या सुमारास माझ्या मनात एक विचार आला. वाचा आणि लिहा (इनपुट/आउटपुट) ऑपरेशन्समध्ये अचूक अंमलबजावणी वेळा समाविष्ट असतात. जेव्हा तुम्ही हार्ड ड्राइव्ह, मेमरी कार्ड किंवा ब्लूटूथ मॉड्यूलसह ​​काम करता, तेव्हा वाचन आणि लेखनासाठी जबाबदार असलेला निम्न-स्तरीय कोड घड्याळाच्या पल्सनुसार असे करतो.

घड्याळाच्या साहाय्याने, प्रोसेसरशी थेट जोडलेले नसलेले उपकरण प्रोसेसरवर कार्यान्वित होणाऱ्या कोडसह सिंक्रोनाइझ केले जाते. घड्याळ बॉड दर ठरवते - डेटा ज्या वेगाने हस्तांतरित केला जातो. वेळेत गोंधळ असेल तर हार्डवेअर किंवा सॉफ्टवेअर किंवा दोन्हीही गोंधळलेले असतात. आणि हे खूप वाईट आहे, कारण डेटा खराब होऊ शकतो.

आमच्या कोडमधील काहीतरी वेळा गोंधळात टाकत असेल तर? मी चाचणी प्रोग्राम कोडमध्ये याशी संबंधित सर्व काही तपासले आणि लक्षात आले की आम्ही PS1 मध्ये प्रोग्राम करण्यायोग्य टाइमर 1 kHz (1000 टिक्स प्रति सेकंद) वर सेट केला आहे. हे बरेच आहे; डीफॉल्टनुसार, जेव्हा कन्सोल सुरू होते, तेव्हा ते 100 Hz वर चालते. आणि बहुतेक गेम ही वारंवारता वापरतात.

अँडी, गेम डेव्हलपर, टाइमर 1 kHz वर सेट केला जेणेकरून हालचाली अधिक अचूकपणे मोजल्या जातील. अँडीला ओव्हरबोर्डमध्ये जाण्याची प्रवृत्ती आहे आणि जर आपण गुरुत्वाकर्षणाचे अनुकरण केले तर आपण ते शक्य तितक्या अचूकपणे करतो!

परंतु टाइमरचा वेग वाढवल्याने प्रोग्रामच्या एकूण वेळेवर आणि म्हणून मेमरी कार्डसाठी बॉड रेट नियंत्रित करणार्‍या घड्याळावर परिणाम झाला तर काय?

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

काही दिवसांनी मी चाचणी कार्यक्रमाचा पुन्हा प्रयोग केला. बग पुनरावृत्ती झाली नाही. मी पूर्ण गेम कोडबेसवर परत गेलो आणि सेव्ह आणि लोड कोडमध्ये बदल केला जेणेकरून मेमरी कार्डमध्ये प्रवेश करण्यापूर्वी प्रोग्रामेबल टायमर त्याच्या मूळ मूल्यावर (100Hz) रीसेट होईल आणि नंतर 1kHz वर रीसेट होईल. आणखी क्रॅश नव्हते.

पण असे का झाले?

मी पुन्हा चाचणी कार्यक्रमात परतलो. मी 1 kHz टाइमरसह त्रुटीच्या घटनेत काही नमुना शोधण्याचा प्रयत्न केला. अखेरीस माझ्या लक्षात आले की जेव्हा एखादी व्यक्ती PS1 कंट्रोलरसह खेळते तेव्हा त्रुटी येते. मी स्वतः हे क्वचितच करत असल्याने - सेव्ह आणि लोड कोडची चाचणी करताना मला कंट्रोलरची आवश्यकता का असेल? - मला हे अवलंबित्व देखील लक्षात आले नाही. पण एके दिवशी आमचा एक कलाकार माझी चाचणी पूर्ण होण्याची वाट पाहत होता - मी कदाचित त्या क्षणी शाप देत होतो - आणि घाबरून त्याच्या हातातला कंट्रोलर फिरवला. त्रुटी आढळली आहे. "थांब काय?!" बरं, पुन्हा कर!”

जेव्हा मला समजले की या दोन घटना एकमेकांशी जोडल्या गेल्या आहेत, तेव्हा मी सहजपणे त्रुटी पुनरुत्पादित करू शकलो: मी मेमरी कार्डवर रेकॉर्डिंग सुरू केले, कंट्रोलर हलवला आणि मेमरी कार्ड खराब केले. माझ्यासाठी ते हार्डवेअर बगसारखे दिसत होते.

मी कोनीकडे आलो आणि तिला माझ्या शोधाबद्दल सांगितले. तिने ही माहिती PS1 डिझाइन करणाऱ्या एका अभियंत्याला दिली. "अशक्य," त्याने उत्तर दिले, "ही हार्डवेअर समस्या असू शकत नाही." मी कॉनीला आमच्यासाठी संभाषणाची व्यवस्था करण्यास सांगितले.

इंजिनियरने मला बोलावले आणि आम्ही त्याच्या तुटलेल्या इंग्रजीत आणि माझ्या (अत्यंत) तुटलेल्या जपानी भाषेत वाद घातला. शेवटी मी म्हणालो, "मला फक्त माझा 30 ओळींचा चाचणी प्रोग्राम पाठवू द्या जिथे कंट्रोलर हलवल्याने बग येतो." त्याने मान्य केले. ते म्हणाले की हा वेळेचा अपव्यय होता आणि तो एका नवीन प्रकल्पावर काम करण्यात कमालीचा व्यस्त होता, परंतु आम्ही सोनीसाठी खूप महत्वाचे विकासक असल्यामुळे ते स्वीकारू. मी माझा चाचणी कार्यक्रम साफ केला आणि त्याला पाठवला.

दुसऱ्या दिवशी संध्याकाळी (आम्ही लॉस एंजेलिसमध्ये होतो आणि तो टोकियोमध्ये होता) त्याने मला कॉल केला आणि मेंढरपणे माफी मागितली. ही एक हार्डवेअर समस्या होती.

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

परंतु तळ ओळ अशी आहे की मदरबोर्डवरील घटकांमध्ये हस्तक्षेप होता. आणि कंट्रोलर पोर्ट आणि मेमरी कार्ड पोर्ट द्वारे एकाच वेळी डेटा प्रसारित करताना 1 kHz वर चालू असलेल्या टायमरसह, बिट गमावले गेले, डेटा गमावला गेला आणि कार्ड खराब झाले.

वाईट गायी

1980 च्या दशकात, माझे गुरू सर्गेई यांनी SM-1800 साठी सॉफ्टवेअर लिहिले, PDP-11 चा सोव्हिएत क्लोन. हा मायक्रो कॉम्प्युटर नुकताच युएसएसआरमधील एक महत्त्वाचा वाहतूक केंद्र असलेल्या स्वेरडलोव्हस्क जवळील रेल्वे स्टेशनवर बसवण्यात आला आहे. नवीन प्रणाली वॅगन आणि मालवाहतुकीच्या मार्गासाठी तयार करण्यात आली होती. परंतु त्यात एक त्रासदायक बग होता ज्यामुळे यादृच्छिक क्रॅश आणि क्रॅश होतात. संध्याकाळी कोणीतरी घरी गेल्यावर नेहमी फॉल्स होते. परंतु दुसर्‍या दिवशी कसून तपासणी करूनही, संगणकाने सर्व मॅन्युअल आणि स्वयंचलित चाचण्यांमध्ये योग्यरित्या कार्य केले. हे सहसा शर्यतीची स्थिती किंवा काही इतर स्पर्धात्मक बग दर्शवते जे काही विशिष्ट परिस्थितीत उद्भवते. रात्री उशिरा कॉल्समुळे कंटाळलेल्या सेर्गेईने तळाशी जाण्याचा निर्णय घेतला आणि सर्व प्रथम, मार्शलिंग यार्डमधील कोणत्या परिस्थितीमुळे संगणक खराब झाला हे समजून घ्या.

प्रथम, त्याने सर्व न समजलेल्या फॉल्सची आकडेवारी गोळा केली आणि तारीख आणि वेळेनुसार आलेख तयार केला. नमुना स्पष्ट होता. आणखी काही दिवस निरीक्षण केल्यानंतर, सर्गेईला जाणवले की तो भविष्यातील सिस्टम अपयशाच्या वेळेचा सहज अंदाज लावू शकतो.

त्याला लवकरच कळले की जेव्हा स्टेशन उत्तर युक्रेन आणि पश्चिम रशियामधून गुरांच्या रेल्वेगाड्यांचे वर्गीकरण करत होते तेव्हाच अडथळे येतात ते जवळच्या कत्तलखान्याकडे जात होते. हे स्वतःच विचित्र होते, कारण कझाकस्तानमध्ये कत्तलखाना अगदी जवळ असलेल्या शेतांद्वारे पुरविला गेला होता.

चेरनोबिल अणुऊर्जा प्रकल्पाचा 1986 मध्ये स्फोट झाला आणि किरणोत्सर्गी परिणामामुळे आजूबाजूचा परिसर निर्जन झाला. उत्तर युक्रेन, बेलारूस आणि पश्चिम रशियामधील विस्तीर्ण भाग दूषित होते. येणाऱ्या गाड्यांमध्ये उच्च पातळीच्या किरणोत्सर्गाचा संशय आल्याने, सर्गेईने या सिद्धांताची चाचणी घेण्यासाठी एक पद्धत विकसित केली. लोकसंख्येला डोसीमीटर ठेवण्यास मनाई होती, म्हणून सेर्गेईने रेल्वे स्थानकावर अनेक लष्करी माणसांसह स्वतःची नोंदणी केली. अनेक वोडका प्यायल्यानंतर, त्याने एका संशयित गाडीतील रेडिएशन पातळी मोजण्यासाठी सैनिकाला पटवून दिले. असे दिसून आले की पातळी सामान्य मूल्यांपेक्षा कित्येक पटीने जास्त आहे.

गुरेढोरे केवळ भरपूर रेडिएशन उत्सर्जित करत नाहीत, तर त्याची पातळी इतकी जास्त होती की स्टेशनच्या शेजारी असलेल्या इमारतीत असलेल्या SM-1800 च्या स्मरणात बिट्सचे यादृच्छिक नुकसान झाले.

यूएसएसआरमध्ये अन्नाचा तुटवडा होता आणि अधिकार्यांनी चेरनोबिल मांस देशाच्या इतर प्रदेशातील मांसाबरोबर मिसळण्याचा निर्णय घेतला. यामुळे मौल्यवान संसाधने न गमावता रेडिओएक्टिव्हिटीची एकूण पातळी कमी करणे शक्य झाले. याबद्दल कळल्यानंतर, सर्गेईने ताबडतोब स्थलांतरासाठी कागदपत्रे भरली. आणि कालांतराने रेडिएशन पातळी कमी झाल्यावर संगणक क्रॅश स्वतःच थांबले.

पाईप्स द्वारे

एकेकाळी मूव्हीटेक सोल्युशन्सने सिनेमासाठी सॉफ्टवेअर तयार केले, जे अकाउंटिंग, तिकीट विक्री आणि सामान्य व्यवस्थापनासाठी डिझाइन केलेले आहे. फ्लॅगशिप अॅपची DOS आवृत्ती उत्तर अमेरिकेतील लहान आणि मध्यम आकाराच्या चित्रपटगृह साखळींमध्ये खूप लोकप्रिय होती. त्यामुळे हे आश्चर्यकारक नाही की जेव्हा Windows 95 आवृत्तीची घोषणा केली गेली, ती नवीनतम टच स्क्रीन आणि सेल्फ-सर्व्हिस किओस्कसह एकत्रित केली गेली आणि सर्व प्रकारच्या रिपोर्टिंग साधनांनी सुसज्ज झाली, तेव्हा ती त्वरीत लोकप्रियही झाली. बर्याचदा अद्यतन समस्यांशिवाय गेले. स्थानिक आयटी कर्मचार्‍यांनी नवीन उपकरणे स्थापित केली, डेटा स्थलांतरित केला आणि व्यवसाय चालू राहिला. जेव्हा ते टिकले नाही तेव्हा वगळता. जेव्हा हे घडले तेव्हा कंपनी जेम्सला "द क्लीनर" असे टोपणनाव पाठवेल.

टोपणनाव एक वाईट प्रकार सूचित करत असले तरी, क्लिनर हे फक्त प्रशिक्षक, इंस्टॉलर आणि जॅक-ऑफ-ऑल-ट्रेडचे संयोजन आहे. जेम्स क्लायंटच्या साइटवर सर्व घटक एकत्र ठेवण्यासाठी काही दिवस घालवतील, आणि नंतर कर्मचार्‍यांना नवीन प्रणाली कशी वापरायची हे शिकवण्यासाठी, उद्भवलेल्या कोणत्याही हार्डवेअर समस्यांचे निराकरण करण्यात आणि मूलत: सॉफ्टवेअरला त्याच्या बालपणात मदत करण्यात आणखी काही दिवस घालवेल.

म्हणूनच, हे आश्चर्यकारक नाही की या व्यस्त काळात, जेम्स सकाळी ऑफिसमध्ये पोहोचला आणि तो त्याच्या डेस्कवर पोहोचण्यापूर्वी, व्यवस्थापकाने त्याचे स्वागत केले, नेहमीपेक्षा जास्त कॅफिनने भरलेले.

"मला भीती वाटते की तुम्हाला लवकरात लवकर अॅनापोलिस, नोव्हा स्कॉशिया येथे जावे लागेल." त्यांची संपूर्ण यंत्रणा कोलमडून गेली आणि त्यांच्या अभियंत्यांसह रात्री काम केल्यानंतर काय झाले ते आम्हाला समजू शकत नाही. असे दिसते की सर्व्हरवर नेटवर्क अयशस्वी झाले आहे. मात्र अनेक मिनिटे यंत्रणा सुरू झाल्यानंतरच.

- ते जुन्या प्रणालीकडे परत आले नाहीत? - जेम्सने पूर्णपणे गंभीरपणे उत्तर दिले, जरी मानसिकदृष्ट्या त्याने आश्चर्याने डोळे मोठे केले.

— तंतोतंत: त्यांच्या IT तज्ञांनी “प्राधान्यक्रम बदलले” आणि त्यांच्या जुन्या सर्व्हरसह जाण्याचा निर्णय घेतला. जेम्स, त्यांनी सहा साइट्सवर सिस्टीम स्थापित केली आणि प्रीमियम समर्थनासाठी पैसे दिले आणि त्यांचा व्यवसाय आता 1950 च्या दशकात चालला आहे.

जेम्स किंचित सरळ झाला.

- ही दुसरी बाब आहे. ठीक आहे, चला सुरुवात करूया.

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

वेश्येला तिच्या वाटेवर पाठवून जेम्स सिनेमाला गेला. आजूबाजूचा परिसर चांगला झाला होता, पण तरीही तो खाली पडल्याचा आभास देत होता. जेम्स खूप काळजीत होता असे नाही. तो याआधी भीषण ठिकाणी गेला आहे. आणि हा कॅनडा होता, जिथे लूट करणारे देखील तुमचे पाकीट घेतल्यावर "धन्यवाद" म्हणण्याइतपत विनम्र आहेत.

सिनेमाचं बाजूचं प्रवेशद्वार गर्द गल्लीत होतं. जेम्स दाराकडे गेला आणि ठोठावला. थोड्याच वेळात ते क्रॅक झाले आणि थोडेसे उघडले.

- तुम्ही क्लिनर आहात का? - आतून कर्कश आवाज आला.

- होय, मीच आहे... मी सर्वकाही ठीक करण्यासाठी आलो आहे.

जेम्स सिनेमाच्या लॉबीमध्ये गेला. वरवर पाहता दुसरा पर्याय नसल्यामुळे कर्मचाऱ्यांनी अभ्यागतांना कागदी तिकिटे देण्यास सुरुवात केली. यामुळे आर्थिक अहवाल देणे कठीण झाले, अधिक मनोरंजक तपशील सोडून द्या. पण कर्मचार्‍यांनी जेम्सला निरोप देत तात्काळ सर्व्हर रूममध्ये नेले.

पहिल्या दृष्टीक्षेपात, सर्वकाही ठीक होते. जेम्सने सर्व्हरमध्ये लॉग इन केले आणि नेहमीच्या संशयास्पद जागा तपासल्या. हरकत नाही. तथापि, भरपूर सावधगिरी बाळगून, जेम्सने सर्व्हर बंद केला, नेटवर्क कार्ड बदलले आणि सिस्टम परत आणली. ती लगेच पूर्ण कामाला लागली. कर्मचाऱ्यांनी पुन्हा तिकिटांची विक्री सुरू केली.

जेम्सने मार्कला फोन करून परिस्थितीची माहिती दिली. जेम्सला आजूबाजूला चिकटून राहून काही अनपेक्षित घडते की नाही हे पाहायचे असेल याची कल्पना करणे कठीण नाही. तो पायऱ्यांवरून खाली उतरला आणि कर्मचाऱ्यांना काय झालं ते विचारू लागला. साहजिकच यंत्रणेने काम करणे बंद केले आहे. त्यांनी ते बंद केले आणि चालू केले, सर्वकाही कार्य केले. मात्र 10 मिनिटांनी यंत्रणा बंद पडली.

नेमके याच क्षणी असेच काहीसे घडले. अचानक तिकीट यंत्रणेत चुका होऊ लागल्या. कर्मचार्‍यांनी उसासा टाकून पेपरची तिकिटे घेतली आणि जेम्स घाईघाईने सर्व्हर रूमकडे गेला. सर्व काही सर्व्हरसह चांगले दिसत होते.

तेवढ्यात एक कर्मचारी आत शिरला.

- सिस्टम पुन्हा काम करत आहे.

जेम्स आश्चर्यचकित झाला कारण त्याने काहीही केले नव्हते. अधिक तंतोतंत, प्रणाली कार्य करेल असे काहीही नाही. त्याने लॉग आउट केले, त्याचा फोन उचलला आणि त्याच्या कंपनीच्या सपोर्ट लाइनला कॉल केला. काही वेळातच तोच कर्मचारी सर्व्हर रूममध्ये शिरला.

- सिस्टम डाउन आहे.

जेम्सने सर्व्हरकडे पाहिले. बहु-रंगीत आकारांचा एक मनोरंजक आणि परिचित नमुना स्क्रीनवर नाचला - गोंधळलेले आणि एकमेकांना जोडलेले पाईप्स. आपण सर्वांनी हा स्क्रीनसेव्हर कधीतरी पाहिला आहे. ते सुंदरपणे रेंडर केले होते आणि अक्षरशः संमोहित होते.

जेम्सने एक बटण दाबले आणि नमुना अदृश्य झाला. तो घाईघाईने तिकीट कार्यालयात गेला आणि वाटेत त्याच्याकडे परतणारा एक कर्मचारी भेटला.

- सिस्टम पुन्हा काम करत आहे.

जर तुम्ही मानसिक फेसपाम करू शकत असाल तर जेम्सने तेच केले. स्क्रीनसेव्हर. हे OpenGL वापरते. आणि म्हणूनच, ऑपरेशन दरम्यान, ते सर्व्हर प्रोसेसरची सर्व संसाधने वापरते. परिणामी, सर्व्हरवरील प्रत्येक कॉल कालबाह्यतेसह समाप्त होतो.

जेम्स सर्व्हर रूममध्ये परतला, लॉग इन केले आणि स्क्रीनसेव्हरला रिकाम्या स्क्रीनसह सुंदर पाईप्सने बदलले. म्हणजेच, 100% प्रोसेसर संसाधने वापरणार्‍या स्क्रीनसेव्हरऐवजी, मी संसाधनांचा वापर न करणारा दुसरा स्थापित केला. मग मी माझा अंदाज तपासण्यासाठी 10 मिनिटे थांबलो.

जेम्स पुढच्या सिनेमात आल्यावर, तो त्याच्या मॅनेजरला कसं समजवायचं याचा विचार करत होता की त्याने स्क्रीन सेव्हर बंद करण्यासाठी फक्त 800 किमी उड्डाण केलं होतं.

चंद्राच्या एका विशिष्ट टप्प्यात क्रॅश

सत्य कथा. एके दिवशी एक सॉफ्टवेअर बग उद्भवला जो चंद्राच्या टप्प्यावर अवलंबून होता. चंद्राच्या खर्‍या टप्प्याची अंदाजे गणना करण्यासाठी एमआयटीच्या विविध कार्यक्रमांमध्ये सामान्यतः वापरला जाणारा एक छोटासा नित्यक्रम होता. GLS ने ही दिनचर्या एका LISP प्रोग्राममध्ये तयार केली जी फाइल लिहिताना जवळपास 80 वर्णांची टाइमस्टॅम्प असलेली एक ओळ आउटपुट करेल. मेसेजची पहिली ओळ खूप मोठी होऊन पुढच्या ओळीत जाणे हे फार दुर्मिळ होते. आणि जेव्हा प्रोग्रामने नंतर ही फाईल वाचली तेव्हा त्याने शाप दिला. पहिल्या ओळीची लांबी अचूक तारीख आणि वेळेवर अवलंबून असते, तसेच टाइमस्टॅम्प मुद्रित करताना फेज तपशीलाची लांबी यावर अवलंबून असते. म्हणजेच, बग अक्षरशः चंद्राच्या टप्प्यावर अवलंबून होता!

पहिली पेपर आवृत्ती शब्दजाल फाइल (स्टील-1983) मध्ये अशा ओळीचे उदाहरण आहे ज्यामुळे वर्णित बग आला, परंतु टाइपसेटरने ते "निश्चित केले". तेव्हापासून याचे वर्णन "मून फेज बग" असे केले जाते.

तथापि, गृहितकांसह सावधगिरी बाळगा. काही वर्षांपूर्वी, CERN (युरोपियन सेंटर फॉर न्यूक्लियर रिसर्च) च्या अभियंत्यांना लार्ज इलेक्ट्रॉन-पोझिट्रॉन कोलायडरवर केलेल्या प्रयोगांमध्ये त्रुटी आल्या. शास्त्रज्ञांना निकाल दाखवण्यापूर्वी संगणक सक्रियपणे या उपकरणाद्वारे व्युत्पन्न केलेल्या प्रचंड प्रमाणात डेटावर प्रक्रिया करत असल्याने, अनेकांनी असा अंदाज लावला की हे सॉफ्टवेअर काही प्रमाणात चंद्राच्या टप्प्यासाठी संवेदनशील होते. अनेक हताश अभियंते सत्याच्या तळापर्यंत पोहोचले. चंद्रावरून जाताना पृथ्वीच्या विकृतीमुळे २७ किमी लांबीच्या रिंगच्या भूमितीत थोडासा बदल झाल्यामुळे ही त्रुटी उद्भवली! या कथेने भौतिकशास्त्रातील लोककथांमध्ये "न्यूटनचा कण भौतिकशास्त्रावरील बदला" म्हणून प्रवेश केला आहे आणि भौतिकशास्त्राचे सर्वात सोपे आणि जुने नियम आणि सर्वात प्रगत वैज्ञानिक संकल्पना यांच्यातील संबंधाचे उदाहरण आहे.

टॉयलेट फ्लश केल्याने ट्रेन थांबते

मी कधीही ऐकलेले सर्वोत्तम हार्डवेअर बग फ्रान्समधील हाय स्पीड ट्रेनमध्ये होते. बगमुळे ट्रेनला आपत्कालीन ब्रेक लावला गेला, परंतु त्यात प्रवासी असतील तरच. अशा प्रत्येक प्रकरणात, ट्रेन सेवेतून बाहेर काढली गेली, तपासली गेली, परंतु काहीही सापडले नाही. मग त्याला परत लाईनवर पाठवण्यात आले आणि तो ताबडतोब एका थांब्यावर कोसळला.

एका तपासणीदरम्यान, ट्रेनमधून प्रवास करणारा एक अभियंता शौचालयात गेला. तो लवकरच वाहून गेला, बूम! आपत्कालीन थांबा.

अभियंत्याने ड्रायव्हरशी संपर्क साधला आणि विचारले:

- ब्रेक लावण्यापूर्वी तुम्ही काय करत होता?

- बरं, मी खाली उतरताना वेग कमी केला...

हे विचित्र होते, कारण सामान्य ऑपरेशन दरम्यान ट्रेन डझनभर वेळा खाली उतरते. ट्रेन पुढे सरकली आणि पुढच्या उतरताना ड्रायव्हरने चेतावणी दिली:

- मी हळू करणार आहे.

काहीच घडलं नाही.

- शेवटच्या ब्रेकिंग दरम्यान तुम्ही काय केले? - ड्रायव्हरला विचारले.

- बरं... मी टॉयलेटमध्ये होतो...

- बरं, मग शौचालयात जा आणि आम्ही पुन्हा खाली गेल्यावर तुम्ही काय केले ते करा!

अभियंता शौचालयात गेला आणि जेव्हा ड्रायव्हरने चेतावणी दिली: “मी कमी करत आहे,” तेव्हा त्याने पाणी सोडले. अर्थात ट्रेन लगेच थांबली.

आता ते समस्येचे पुनरुत्पादन करू शकतात आणि कारण शोधणे आवश्यक आहे.

दोन मिनिटांनंतर, त्यांच्या लक्षात आले की इंजिन ब्रेक रिमोट कंट्रोल केबल (ट्रेनला प्रत्येक टोकाला एक इंजिन होते) इलेक्ट्रिकल कॅबिनेटच्या भिंतीपासून डिस्कनेक्ट केले गेले होते आणि टॉयलेट प्लग सोलेनोइड नियंत्रित करणार्‍या रिलेवर पडले होते... जेव्हा रिले चालू केले होते, यामुळे ब्रेक केबलमध्ये हस्तक्षेप निर्माण झाला आणि अपयशाविरूद्ध सिस्टम संरक्षणामध्ये फक्त आपत्कालीन ब्रेकिंग समाविष्ट होते.

फोरट्रानचा तिरस्कार करणारा प्रवेशद्वार

काही महिन्यांपूर्वी आमच्या लक्षात आले की मुख्य भूमीवरील नेटवर्क कनेक्शन [हे हवाईमध्ये होते] खूप, खूप मंद होत आहेत. हे 10-15 मिनिटे टिकू शकते आणि नंतर अचानक पुन्हा येऊ शकते. काही काळानंतर, माझ्या सहकाऱ्याने मला तक्रार केली की मुख्य भूमीवरील नेटवर्क कनेक्शन सर्वसाधारणपणे काम करत नाही. त्याच्याकडे काही FORTRAN कोड होता ज्याची मुख्य भूमीवरील मशीनवर कॉपी करणे आवश्यक होते, परंतु ते शक्य झाले नाही कारण "नेटवर्कने FTP अपलोड पूर्ण होण्यासाठी पुरेसा वेळ धरला नाही."

होय, असे दिसून आले की जेव्हा एका सहकाऱ्याने फोरट्रानमधील स्त्रोत कोड असलेली फाइल मुख्य भूमीवरील मशीनवर FTP करण्याचा प्रयत्न केला तेव्हा नेटवर्क अपयशी झाले. आम्ही फाइल संग्रहित करण्याचा प्रयत्न केला: नंतर ती सहजतेने कॉपी केली गेली (परंतु लक्ष्य मशीनमध्ये अनपॅकर नव्हते, त्यामुळे समस्या सोडवली गेली नाही). शेवटी आम्ही FORTRAN कोडला अगदी लहान तुकड्यांमध्ये "विभाजित" केले आणि एका वेळी एक पाठवले. बहुतेक तुकडे समस्यांशिवाय कॉपी केले गेले, परंतु काही तुकडे पास झाले नाहीत किंवा नंतर पास झाले असंख्य प्रयत्न

जेव्हा आम्ही समस्याप्रधान परिच्छेदांचे परीक्षण केले तेव्हा आम्हाला आढळले की त्यांच्यात काहीतरी साम्य आहे: त्या सर्वांमध्ये कमेंट ब्लॉक्स आहेत जे कॅपिटल C असलेल्या ओळींनी सुरू झाले आणि समाप्त झाले (फोरट्रानमध्ये एका सहकाऱ्याने टिप्पणी देण्यास प्राधान्य दिले). आम्ही मुख्य भूभागावरील नेटवर्क तज्ञांना ईमेल केले आणि मदत मागितली. अर्थात, त्यांना आमच्या फायलींचे नमुने पहायचे होते ज्या FTP द्वारे हस्तांतरित केल्या जाऊ शकत नाहीत... परंतु आमची पत्रे त्यांच्यापर्यंत पोहोचली नाहीत. शेवटी आम्ही एक साधी गोष्ट घेऊन आलो वर्णन करणेहस्तांतरणीय नसलेल्या फायली कशा दिसतात. हे कार्य केले :) [मी येथे समस्याग्रस्त फोरट्रान टिप्पण्यांपैकी एक उदाहरण जोडू इच्छितो? कदाचित त्याची किंमत नाही!]

शेवटी आम्ही ते शोधण्यात व्यवस्थापित झालो. आमच्या कॅम्पसचा भाग आणि मुख्य भूभागाच्या नेटवर्कमध्ये नुकतेच एक नवीन गेटवे स्थापित केले गेले. अप्परकेस सी चे वारंवार बिट असलेली पॅकेट्स प्रसारित करण्यात प्रचंड अडचण होती! यापैकी काही पॅकेट्स सर्व गेटवे संसाधने घेऊ शकतात आणि इतर बहुतेक पॅकेट्समधून जाण्यापासून रोखू शकतात. आम्ही गेटवे निर्मात्याकडे तक्रार केली... आणि त्यांनी उत्तर दिले: “अरे, होय, तुम्हाला वारंवार C च्या बगचा सामना करावा लागतो! आम्हाला त्याच्याबद्दल आधीच माहिती आहे.” आम्ही शेवटी दुसर्‍या निर्मात्याकडून नवीन गेटवे खरेदी करून समस्येचे निराकरण केले (पूर्वीच्या संरक्षणात, FORTRAN प्रोग्राम हस्तांतरित करण्यास असमर्थता काहींसाठी एक फायदा असू शकते!).

कठीण वेळा

काही वर्षांपूर्वी, फेज 40 क्लिनिकल चाचण्यांचा खर्च कमी करण्यासाठी पर्लमध्ये ETL प्रणाली तयार करण्यावर काम करत असताना, मला सुमारे 000 तारखांवर प्रक्रिया करावी लागली. त्यापैकी दोन परीक्षार्थी उत्तीर्ण झाले नाहीत. याचा मला फारसा त्रास झाला नाही कारण या तारखा क्लायंट-प्रदान केलेल्या डेटामधून घेतल्या गेल्या आहेत, जे आम्ही म्हणू का, आश्चर्यकारक. परंतु जेव्हा मी मूळ डेटा तपासला तेव्हा असे दिसून आले की या तारखा 1 जानेवारी 2011 आणि 1 जानेवारी 2007 आहेत. मला वाटले की मी नुकत्याच लिहिलेल्या प्रोग्राममध्ये बग समाविष्ट आहे, परंतु असे दिसून आले की ते आधीच 30 वर्षे झाले आहे. जुन्या. सॉफ्टवेअर इकोसिस्टमशी परिचित नसलेल्यांना हे अनाकलनीय वाटू शकते. दुसर्‍या कंपनीने पैसे कमवण्याच्या दीर्घकाळाच्या निर्णयामुळे, माझ्या क्लायंटने मला एका कंपनीने अपघाताने आणि दुसर्‍याने हेतुपुरस्सर आणलेल्या बगचे निराकरण करण्यासाठी पैसे दिले. मी कशाबद्दल बोलत आहे हे तुम्हाला समजण्यासाठी, मला त्या कंपनीबद्दल बोलणे आवश्यक आहे ज्याने वैशिष्ट्य जोडले जे बग बनले, तसेच काही इतर मनोरंजक घटना ज्यांनी मी निराकरण केलेल्या रहस्यमय बगमध्ये योगदान दिले.

चांगल्या जुन्या दिवसांमध्ये, ऍपल संगणक कधीकधी उत्स्फूर्तपणे त्यांची तारीख 1 जानेवारी 1904 वर रीसेट करत असत. कारण सोपे होते: तारीख आणि वेळेचा मागोवा ठेवण्यासाठी बॅटरीवर चालणारे "सिस्टम घड्याळ" वापरले. बॅटरी मेली तेव्हा काय झाले? एका युगाच्या सुरुवातीपासून संगणकांनी सेकंदांच्या संख्येने तारखेचा मागोवा घेण्यास सुरुवात केली. युगानुसार आमचा संदर्भ मूळ तारीख असा होता आणि मॅकिंटोशसाठी ती 1 जानेवारी 1904 होती. आणि बॅटरी संपल्यानंतर, वर्तमान तारीख निर्दिष्ट तारखेवर रीसेट केली गेली. पण असे का झाले?

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

तथापि, ऍपलच्या युगापासूनच्या तारखा सेकंदांच्या रूपात संग्रहित करण्याच्या निर्णयाचा अर्थ असा होतो की आम्ही युगापूर्वीच्या तारखा हाताळू शकत नाही, ज्याचे दूरगामी परिणाम होते, जसे आपण पाहू. ऍपलने एक फीचर सादर केले, बग नाही. इतर गोष्टींबरोबरच, याचा अर्थ असा होतो की मॅकिंटॉश ऑपरेटिंग सिस्टम “मिलेनियम बग” (जे अनेक मॅक ऍप्लिकेशन्स बद्दल सांगितले जाऊ शकत नाही ज्यांच्या निर्बंधांना दूर ठेवण्यासाठी त्यांची स्वतःची तारीख प्रणाली होती) पासून प्रतिकारशक्ती होती.

पुढे जा. आम्ही लोटस 1-2-3, IBM चे "किलर ऍप्लिकेशन" वापरले ज्याने PC क्रांती सुरू करण्यास मदत केली, जरी Apple संगणकांमध्ये VisiCalc होते, ज्यामुळे वैयक्तिक संगणक यशस्वी झाला. प्रामाणिकपणे, जर 1-2-3 दिसला नसता, तर PC क्वचितच बंद झाले असते आणि वैयक्तिक संगणकाचा इतिहास खूप वेगळ्या पद्धतीने विकसित होऊ शकला असता. लोटस 1-2-3 चुकीच्या पद्धतीने 1900 ला लीप वर्ष मानले. जेव्हा मायक्रोसॉफ्टने त्याची पहिली स्प्रेडशीट, मल्टीप्लान जारी केली, तेव्हा त्याने बाजारपेठेचा एक छोटासा हिस्सा मिळवला. आणि जेव्हा त्यांनी Excel प्रकल्प लाँच केला, तेव्हा त्यांनी Lotus 1-2-3 मधील पंक्ती आणि स्तंभ नामकरण योजना कॉपी करण्याचा निर्णय घेतला नाही तर मुद्दाम 1900 ला लीप वर्ष मानून बग सुसंगतता सुनिश्चित करण्याचा निर्णय घेतला. ही समस्या आजही कायम आहे. म्हणजेच, 1-2-3 मध्ये हा एक बग होता, परंतु Excel मध्ये हा एक जाणीवपूर्वक निर्णय होता ज्यामुळे सर्व 1-2-3 वापरकर्ते डेटा न बदलता त्यांची टेबल्स Excel मध्ये आयात करू शकतात, जरी ते चुकीचे असले तरीही.

पण दुसरी अडचण होती. प्रथम, मायक्रोसॉफ्टने मॅकिंटॉशसाठी एक्सेल जारी केला, ज्यात 1 जानेवारी 1904 पूर्वीच्या तारखा ओळखल्या जात नाहीत. आणि एक्सेलमध्ये, 1 जानेवारी, 1900 ही युगाची सुरुवात मानली गेली. म्हणून, विकासकांनी एक बदल केला ज्यामुळे त्यांच्या प्रोग्रामने युगाचा प्रकार ओळखला आणि इच्छित युगाच्या अनुषंगाने डेटा स्वतःमध्ये संग्रहित केला. मायक्रोसॉफ्टने याबद्दल एक स्पष्टीकरणात्मक लेख देखील लिहिला आहे. आणि या निर्णयामुळे मला बग आला.

माझ्या ETL सिस्टीमला Windows वर तयार केलेल्या ग्राहकांकडून Excel स्प्रेडशीट मिळाल्या, परंतु Mac वर देखील तयार केल्या जाऊ शकतात. म्हणून, टेबलमधील युगाची सुरुवात एकतर 1 जानेवारी 1900 किंवा 1 जानेवारी 1904 असू शकते. कसे शोधायचे? एक्सेल फाईल फॉरमॅट आवश्यक माहिती दाखवते, परंतु मी वापरलेले पार्सरने ते दाखवले नाही (आता ते दाखवते), आणि असे गृहीत धरले की तुम्हाला विशिष्ट टेबलसाठी युग माहित आहे. मी कदाचित एक्सेल बायनरी फॉरमॅट समजून घेण्यात आणि पार्सर लेखकाला पॅच पाठवण्यात अधिक वेळ घालवू शकलो असतो, परंतु क्लायंटसाठी मला बरेच काही करायचे होते, म्हणून मी त्वरीत युग निश्चित करण्यासाठी एक ह्युरिस्टिक लिहिले. ती साधी होती.

एक्सेलमध्ये, 5 जुलै 1998 ही तारीख "07-05-98" (निरुपयोगी अमेरिकन प्रणाली), "जुलै 5, 98", "5 जुलै, 1998", "5-जुलै-98" या स्वरूपात दर्शविली जाऊ शकते. दुसरे काही स्वरूप. दुसरे निरुपयोगी स्वरूप (विडंबनाने, माझ्या एक्सेलच्या आवृत्तीने ऑफर केलेल्या स्वरूपांपैकी एक म्हणजे ISO 8601). तथापि, सारणीमध्ये, अनफॉर्मेट केलेली तारीख एकतर epoch-35981 साठी "1900" किंवा epoch-34519 साठी "1904" म्हणून संग्रहित केली गेली होती (संख्या युगापासूनच्या दिवसांची संख्या दर्शवते). फॉरमॅट केलेल्या तारखेपासून वर्ष काढण्यासाठी मी फक्त एक साधा पार्सर वापरला आणि नंतर अनफॉर्मेट केलेल्या तारखेपासून वर्ष काढण्यासाठी एक्सेल पार्सर वापरला. जर दोन्ही मूल्ये 4 वर्षांनी भिन्न असतील, तर मला माहित आहे की मी epoch-1904 सह सिस्टम वापरत आहे.

मी फक्त स्वरूपित तारखा का वापरल्या नाहीत? कारण 5 जुलै, 1998 हे महिन्याच्या हरवलेल्या दिवसासह "जुलै, 98" असे स्वरूपित केले जाऊ शकते. आम्हाला बर्‍याच कंपन्यांकडून टेबल प्राप्त झाले ज्यांनी त्यांना इतक्या वेगवेगळ्या प्रकारे तयार केले की तारखा शोधणे आमच्यावर अवलंबून आहे (या प्रकरणात, मी). शिवाय, जर एक्सेलला ते बरोबर मिळत असेल, तर आपणही तसे केले पाहिजे!

त्याच वेळी मला 39082 भेटले. मी तुम्हाला आठवण करून देतो की लोटस 1-2-3 ने 1900 ला लीप वर्ष मानले होते आणि एक्सेलमध्ये याची प्रामाणिकपणे पुनरावृत्ती होते. आणि याने वर्ष 1900 मध्ये एक दिवस जोडला असल्याने, त्या दिवसासाठी अनेक तारीख गणना कार्ये चुकीची असू शकतात. म्हणजेच, 39082 1 जानेवारी 2011 (Macs वर) किंवा 31 डिसेंबर 2006 (Windows वर) असू शकते. जर माझ्या “वर्ष पार्सर” ने फॉर्मेट केलेल्या मूल्यातून 2011 हे वर्ष काढले असेल, तर सर्व काही ठीक आहे. परंतु एक्सेल पार्सरला कोणता युग वापरला जात आहे हे माहित नसल्यामुळे, ते epoch-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 च्या दशकाच्या सुरुवातीस, माझ्या वडिलांनी स्टोरेज टेक्नॉलॉजीमध्ये काम केले, जो आता बंद झालेला विभाग आहे ज्याने हाय-स्पीड टेप फीडिंगसाठी टेप ड्राइव्ह आणि वायवीय प्रणाली तयार केली.

त्यांनी ड्राइव्हची पुनर्रचना केली जेणेकरून त्यांच्याकडे एक मध्यवर्ती "A" ड्राइव्ह सात "B" ड्राइव्हशी जोडलेला असेल आणि "A" ड्राइव्ह नियंत्रित करणार्‍या RAM मधील लहान OS सर्व "B" ड्राइव्हवर वाचन आणि लेखन ऑपरेशन्स सोपवू शकेल.

प्रत्येक वेळी "A" ड्राइव्ह सुरू केल्यावर, ऑपरेटिंग सिस्टमला त्याच्या मेमरीमध्ये लोड करण्यासाठी "A" शी कनेक्ट केलेल्या परिधीय ड्राइव्हमध्ये फ्लॉपी डिस्क घालणे आवश्यक होते. हे अत्यंत प्राचीन होते: संगणकीय शक्ती 8-बिट मायक्रोकंट्रोलरद्वारे प्रदान केली गेली होती.

अशा उपकरणांचे लक्ष्य प्रेक्षक हे खूप मोठे डेटा वेअरहाऊस असलेल्या कंपन्या होत्या - बँका, किरकोळ साखळी इ. - ज्यांना बरीच पत्ते लेबले किंवा बँक स्टेटमेंट छापणे आवश्यक होते.

एका क्लायंटला समस्या होती. प्रिंट जॉबच्या मध्यभागी, एक विशिष्ट ड्राइव्ह “A” कार्य करणे थांबवू शकते, ज्यामुळे संपूर्ण कार्य थांबेल. ड्राइव्हचे ऑपरेशन पुनर्संचयित करण्यासाठी, कर्मचार्‍यांना सर्वकाही रीबूट करावे लागले. आणि जर हे सहा तासांच्या कार्याच्या मध्यभागी घडले तर, संगणकाचा प्रचंड वेळ वाया गेला आणि संपूर्ण ऑपरेशनचे वेळापत्रक विस्कळीत झाले.

स्टोरेज टेक्नॉलॉजीजमधून तंत्रज्ञ पाठवले होते. परंतु त्यांच्या सर्वोत्कृष्ट प्रयत्नांनंतरही, ते चाचणी परिस्थितीत बगचे पुनरुत्पादन करू शकले नाहीत: मोठ्या प्रिंट जॉब्सच्या मध्यभागी असे दिसते. समस्या हार्डवेअरची नव्हती, त्यांनी जे काही शक्य होते ते बदलले: RAM, मायक्रोकंट्रोलर, फ्लॉपी ड्राइव्ह, टेप ड्राइव्हचा प्रत्येक कल्पनीय भाग - समस्या कायम राहिली.

मग तंत्रज्ञांनी मुख्यालयात बोलावून तज्ञांना बोलावले.

तज्ञाने एक खुर्ची आणि कॉफीचा कप घेतला, संगणकाच्या खोलीत बसला - त्या दिवसात संगणकांना समर्पित खोल्या होत्या - आणि कर्मचारी मोठ्या प्रिंट जॉबच्या रांगेत उभे असताना पाहत होते. तज्ञ अपयशी होण्याची वाट पाहत होते - आणि तसे झाले. सगळ्यांनी एक्सपर्टकडे बघितलं, पण असं का झालं ते कळत नव्हतं. त्यामुळे त्यांनी कामाला पुन्हा रांगेत उभे राहण्याचे आदेश दिले आणि सर्व कर्मचारी आणि तंत्रज्ञ कामावर परतले.

तज्ञ पुन्हा खुर्चीत बसला आणि अपयशाची वाट पाहू लागला. सुमारे सहा तास उलटले आणि बिघाड झाला. तज्ञांना पुन्हा कोणतीही कल्पना नव्हती, त्याशिवाय सर्व काही माणसांनी भरलेल्या खोलीत घडले. त्याने मिशन पुन्हा सुरू करण्याचा आदेश दिला, परत खाली बसला आणि वाट पाहू लागला.

तिसऱ्या अपयशाने, तज्ञाच्या लक्षात आले. जेव्हा कर्मचार्‍यांनी परदेशी ड्राइव्हमध्ये टेप बदलला तेव्हा अपयश आले. शिवाय, कर्मचार्‍यांपैकी एक मजल्यावरील विशिष्ट टाइलमधून चालत असतानाच बिघाड झाला.

उंच मजला 6 ते 8 इंच उंचीवर ठेवलेल्या अॅल्युमिनियम टाइल्सचा बनलेला होता. एखाद्या महत्त्वाच्या केबलवर चुकून कोणी पाऊल ठेवू नये म्हणून संगणकातील असंख्य वायर उंच मजल्याखाली धावल्या. वरच्या मजल्याखाली मलबा येऊ नये म्हणून फरशा अतिशय घट्ट घातल्या होत्या.

तज्ञाच्या लक्षात आले की टाइलपैकी एक विकृत आहे. जेव्हा एक कर्मचारी त्याच्या कोपऱ्यावर पाऊल ठेवतो तेव्हा टाइलच्या कडा शेजारील टाइलच्या विरूद्ध घासल्या जातात. टाइलला जोडलेले प्लास्टिकचे भाग देखील त्यांच्याबरोबर घासले, ज्यामुळे स्थिर मायक्रोडिस्चार्ज झाले ज्यामुळे रेडिओ फ्रिक्वेंसी हस्तक्षेप निर्माण झाला.

आज, RAM रेडिओ फ्रिक्वेंसी हस्तक्षेपापासून अधिक चांगले संरक्षित आहे. पण त्या वर्षांत असे नव्हते. तज्ञाच्या लक्षात आले की या हस्तक्षेपामुळे मेमरी विस्कळीत होते आणि त्यासह ऑपरेटिंग सिस्टमचे कार्य होते. त्याने सपोर्ट सर्व्हिसला कॉल केला, नवीन टाइल्स ऑर्डर केल्या, त्या स्वतः स्थापित केल्या आणि समस्या अदृश्य झाली.

भरती आहे!

ही कथा एका सर्व्हर रूममध्ये घडली, पोर्ट्समाउथ (माझ्या मते), डॉक्स परिसरात ऑफिसच्या चौथ्या किंवा पाचव्या मजल्यावर.

एके दिवशी मुख्य डेटाबेससह युनिक्स सर्व्हर क्रॅश झाला. त्यांनी त्याला रीबूट केले, परंतु तो आनंदाने पुन्हा पुन्हा पडत राहिला. आम्ही सपोर्ट सेवेमधून एखाद्याला कॉल करण्याचे ठरवले.

सपोर्ट माणूस... मला वाटतं त्याचं नाव मार्क होतं, पण काही फरक पडत नाही... मला वाटत नाही की मी त्याला ओळखतो. काही फरक पडत नाही, खरोखर. चला मार्कला चिकटून राहूया, ठीक आहे? मस्त.

तर, काही तासांनंतर मार्क आला (लीड्स ते पोर्ट्समाउथ हा फार मोठा पल्ला नाही, तुम्हाला माहिती आहे), सर्व्हर चालू केला आणि सर्व काही समस्यांशिवाय काम करत होते. टिपिकल डॅम सपोर्ट, क्लायंट याबद्दल खूप नाराज होतो. मार्क लॉग फायलींमधून पाहतो आणि त्याला काहीही अप्रिय आढळले नाही. त्यामुळे मार्क ट्रेनमध्ये परतला (किंवा तो कोणत्याही वाहतुकीच्या मार्गाने आला असेल, मला माहीत असलेल्या सर्वांसाठी ती एक लंगडी गाय असू शकते... तरीही, काही फरक पडत नाही, ठीक आहे?) आणि वाया घालवून लीड्सला परत जातो. दिवस.

त्याच संध्याकाळी सर्व्हर पुन्हा क्रॅश झाला. कथा एकच आहे... सर्व्हर उठत नाही. मार्क दूरस्थपणे मदत करण्याचा प्रयत्न करतो, परंतु क्लायंट सर्व्हर सुरू करू शकत नाही.

दुसरी ट्रेन, बस, लिंबू मेरिंग्यू किंवा इतर काही बकवास, आणि मार्क पोर्ट्समाउथला परत आला आहे. पहा, सर्व्हर कोणत्याही अडचणीशिवाय बूट होतो! चमत्कार. ऑपरेटिंग सिस्टम किंवा सॉफ्टवेअरसह सर्वकाही व्यवस्थित आहे हे तपासण्यात मार्क अनेक तास घालवतो आणि लीड्सला निघतो.

दिवसाच्या मध्यभागी सर्व्हर क्रॅश होतो (हे सोपे घ्या!). यावेळी सर्व्हर बदलण्यासाठी हार्डवेअर सपोर्ट लोकांना आणणे वाजवी वाटते. पण नाही, सुमारे 10 तासांनंतर तो देखील पडतो.

अनेक दिवस परिस्थितीची पुनरावृत्ती झाली. सर्व्हर काम करतो, सुमारे 10 तासांनंतर क्रॅश होतो आणि पुढील 2 तास सुरू होत नाही. त्यांनी कूलिंग, मेमरी लीक तपासले, त्यांनी सर्वकाही तपासले, परंतु काहीही सापडले नाही. त्यानंतर अपघात थांबले.

आठवडा निश्चिंतपणे गेला... सर्वजण आनंदात होते. हे सर्व पुन्हा सुरू होईपर्यंत आनंदी. चित्र तेच आहे. 10 तास काम, 2-3 तास डाउनटाइम...

आणि मग कोणीतरी (मला वाटते की त्यांनी मला सांगितले की या व्यक्तीचा आयटीशी काहीही संबंध नाही) म्हणाले:

"ओहोटी आहे!"

उद्गार रिक्त ताकांसह भेटले होते आणि सुरक्षा कॉल बटणावर कोणाचा तरी हात बहुधा संकोचत होता.

"ते भरतीसह काम करणे थांबवते."

आयटी सपोर्ट कर्मचार्‍यांना ही पूर्णपणे परदेशी संकल्पना वाटेल, जे कॉफीसाठी बसून टाइड इयरबुक वाचण्याची शक्यता नाही. त्यांनी स्पष्ट केले की हे कोणत्याही प्रकारे भरतीशी संबंधित असू शकत नाही, कारण सर्व्हर एका आठवड्यापासून अपयशी न होता काम करत होता.

"गेल्या आठवड्यात भरती कमी होती, पण या आठवड्यात ती जास्त आहे."

ज्यांच्याकडे नौका परवाना नाही त्यांच्यासाठी थोडीशी शब्दावली. भरती चंद्राच्या चक्रावर अवलंबून असतात. आणि पृथ्वी फिरत असताना, प्रत्येक 12,5 तासांनी सूर्य आणि चंद्राच्या गुरुत्वाकर्षणाच्या खेचामुळे एक भरती-ओहोटी निर्माण होते. 12,5-तासांच्या चक्राच्या सुरूवातीस एक उच्च भरती आहे, सायकलच्या मध्यभागी एक ओहोटी आहे आणि शेवटी पुन्हा उच्च भरती आहे. पण चंद्राची कक्षा बदलत असल्याने कमी आणि उंच भरतीमधील फरकही बदलतो. जेव्हा चंद्र सूर्य आणि पृथ्वीच्या दरम्यान असतो किंवा पृथ्वीच्या विरुद्ध बाजूस असतो (पौर्णिमा किंवा चंद्र नाही), तेव्हा आपल्याला सिझिगिन भरती येतात - सर्वात जास्त उंच भरती आणि सर्वात कमी कमी भरती. अर्ध्या चंद्रावर आपल्याला चतुर्भुज भरती येतात - सर्वात कमी भरती. दोन टोकांमधील फरक खूप कमी होतो. चंद्र चक्र 28 दिवस टिकते: syzygian - quadrature - syzygian - quadrature.

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

रॉकेटसाठी फ्लाइट मिशन

मला एक मोठी (सुमारे 400 हजार ओळी) रॉकेट लॉन्च कंट्रोल आणि मॉनिटरिंग सिस्टम ऑपरेटिंग सिस्टम, कंपाइलर आणि भाषेच्या नवीन आवृत्त्यांमध्ये पोर्ट करण्याचे काम देण्यात आले होते. अधिक तंतोतंत, सोलारिस 2.5.1 पासून सोलारिस 7 पर्यंत, आणि Ada 83 मध्ये लिहिलेल्या Verdix Ada Development System (VADS) पासून, Ada 95 मध्ये लिहिलेल्या Rational Apex Ada सिस्टम पर्यंत. VADS Rational ने खरेदी केले होते आणि त्याचे उत्पादन होते. अप्रचलित, जरी Rational ने Apex compiler मध्ये संक्रमण सुलभ करण्यासाठी VADS-विशिष्ट पॅकेजेसच्या सुसंगत आवृत्त्या लागू करण्याचा प्रयत्न केला.

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

आणि थँक्सगिव्हिंगच्या आदल्या शुक्रवारी फोन वाजला.

रॉकेट प्रक्षेपणाची चाचणी सुमारे तीन आठवड्यांत होणार होती आणि काउंटडाउनच्या प्रयोगशाळेच्या चाचण्यांदरम्यान, आदेशांचा क्रम अवरोधित केला गेला. वास्तविक जीवनात, हे चाचणी रद्द करेल, आणि जर इंजिन सुरू झाल्यानंतर काही सेकंदात अडथळा निर्माण झाला, तर सहाय्यक प्रणालींमध्ये अनेक अपरिवर्तनीय क्रिया घडतील, ज्यासाठी रॉकेटची दीर्घ - आणि महाग - तयारी आवश्यक असेल. ते सुरू झाले नसते, परंतु बरेच लोक वेळ आणि भरपूर, भरपूर पैसे गमावल्याबद्दल खूप नाराज झाले असते. संरक्षण विभाग अविचारीपणे पैसे खर्च करतो हे कोणालाही सांगू देऊ नका—मी कधीही अशा कंत्राटी व्यवस्थापकाला भेटलो नाही ज्याने बजेट प्रथम किंवा दुसरे, वेळापत्रकानुसार ठेवले नाही.

मागील महिन्यांत, हे काउंटडाउन आव्हान शेकडो वेळा अनेक भिन्नतांमध्ये चालवले गेले होते, फक्त काही किरकोळ अडथळ्यांसह. त्यामुळे असे घडण्याची शक्यता फारच कमी होती, परंतु त्याचे परिणाम खूप लक्षणीय होते. या दोन्ही घटकांचा गुणाकार करा, आणि तुम्हाला समजेल की या बातमीने माझ्यासाठी आणि डझनभर अभियंते आणि व्यवस्थापकांसाठी सुट्टीचा आठवडा उध्वस्त होण्याची भविष्यवाणी केली आहे.

आणि सिस्टम पोर्ट करणारी व्यक्ती म्हणून माझ्याकडे लक्ष दिले गेले.

बर्‍याच सुरक्षा-गंभीर प्रणालींप्रमाणे, बरेच पॅरामीटर्स लॉग केले गेले होते, त्यामुळे सिस्टम क्रॅश होण्यापूर्वी अंमलात आणलेल्या कोडच्या काही ओळी ओळखणे अगदी सोपे होते. आणि अर्थातच, त्यांच्याबद्दल असामान्य काहीही नव्हते; त्याच रन दरम्यान समान अभिव्यक्ती अक्षरशः हजारो वेळा यशस्वीरित्या अंमलात आणली गेली.

आम्ही Apex मधील लोकांना Rational मध्ये बोलावले कारण त्यांनीच कंपाइलर विकसित केले होते आणि त्यांनी विकसित केलेल्या काही दिनचर्या संशयास्पद कोडमध्ये कॉल केल्या होत्या. अक्षरशः राष्ट्रीय महत्त्वाच्या समस्येच्या मुळाशी जाण्याची गरज आहे हे त्यांना (आणि इतर सर्वांनी) प्रभावित केले.

जर्नल्समध्ये काहीही मनोरंजक नसल्यामुळे, आम्ही स्थानिक प्रयोगशाळेत समस्येचे पुनरुत्पादन करण्याचा प्रयत्न करण्याचा निर्णय घेतला. हे सोपे काम नव्हते कारण प्रत्येक 1000 धावांवर हा कार्यक्रम अंदाजे एकदा आला. एक संशयित कारण म्हणजे विक्रेता-विकसित म्युटेक्स फंक्शनला कॉल (VADS मायग्रेशन पॅकेजचा भाग) Unlock अनलॉक करण्यासाठी नेले नाही. प्रोसेसिंग थ्रेड ज्याला फंक्शन म्हणतात तो हृदयाचे ठोके संदेशांवर प्रक्रिया करतो, जे नाममात्र दर सेकंदाला येतात. आम्ही वारंवारता 10 Hz पर्यंत वाढवली, म्हणजेच प्रति सेकंद 10 वेळा, आणि धावू लागलो. सुमारे एक तासानंतर सिस्टम स्वतःच लॉक झाली. लॉगमध्ये, आम्ही पाहिले की रेकॉर्ड केलेल्या संदेशांचा क्रम अयशस्वी चाचणी दरम्यान सारखाच होता. आम्ही आणखी अनेक धावा केल्या, प्रणाली सुरू झाल्यानंतर 45-90 मिनिटांनी सातत्याने अवरोधित केली गेली आणि प्रत्येक वेळी लॉगमध्ये समान मार्ग होता. जरी आम्ही तांत्रिकदृष्ट्या भिन्न कोड चालवत होतो - संदेश वारंवारता भिन्न होती - सिस्टमचे वर्तन समान होते, म्हणून आम्हाला खात्री होती की या लोड परिस्थितीमुळे समान समस्या उद्भवत आहे.

आता आपल्याला अभिव्यक्तीच्या अनुक्रमात ब्लॉकिंग नेमके कुठे होते हे शोधणे आवश्यक आहे.

प्रणालीच्या या अंमलबजावणीने Ada कार्य प्रणाली वापरली आणि ती अविश्वसनीयपणे खराब वापरली. टास्क ही Ada मधील उच्च-स्तरीय एकाचवेळी एक्झिक्युटेबल रचना आहे, जे एक्झिक्यूशनच्या थ्रेड्ससारखे आहे, फक्त भाषेमध्येच तयार केले आहे. जेव्हा दोन कार्यांना संवाद साधण्याची आवश्यकता असते, तेव्हा ते "एक भेट सेट करतात", आवश्यक डेटाची देवाणघेवाण करतात आणि नंतर भेट थांबवतात आणि त्यांच्या स्वतंत्र अंमलबजावणीकडे परत जातात. मात्र, ही यंत्रणा वेगळ्या पद्धतीने राबवण्यात आली. लक्ष्य टास्क भेटल्यानंतर, ते लक्ष्य टास्क दुसर्‍या टास्कसह एकत्र केले जाते, जे नंतर तिसऱ्या टास्कसह एकत्र केले जाते आणि काही प्रक्रिया पूर्ण होईपर्यंत असेच चालू होते. यानंतर, ही सर्व भेट पूर्ण झाली आणि प्रत्येक कार्य त्याच्या अंमलबजावणीकडे परत जावे लागले. म्हणजेच, आम्ही जगातील सर्वात महाग फंक्शन कॉल सिस्टम हाताळत होतो, ज्याने इनपुट डेटाच्या काही भागावर प्रक्रिया करताना संपूर्ण “मल्टीटास्किंग” प्रक्रिया थांबवली. आणि याआधी केवळ थ्रुपुट खूप कमी असल्यामुळे समस्या निर्माण झाल्या नाहीत.

मी या कार्य यंत्रणेचे वर्णन केले कारण जेव्हा भेटीची विनंती केली गेली किंवा पूर्ण होण्याची अपेक्षा केली गेली, तेव्हा "टास्क स्विच" होऊ शकते. म्हणजेच, प्रोसेसर कार्यान्वित होण्यासाठी तयार असलेल्या दुसर्‍या कार्यावर प्रक्रिया करण्यास प्रारंभ करू शकतो. असे दिसून येते की जेव्हा एखादे कार्य दुसर्‍या कार्यास भेटण्यासाठी तयार असते, तेव्हा एक पूर्णपणे भिन्न कार्य कार्यान्वित होण्यास सुरवात होते आणि शेवटी नियंत्रण पहिल्या भेटीवर परत येते. आणि इतर घटना घडू शकतात ज्यामुळे कार्य स्विच होते; अशी एक घटना म्हणजे सिस्टम फंक्शनला कॉल करणे, जसे की म्युटेक्स प्रिंट करणे किंवा कार्यान्वित करणे.

कोडच्या कोणत्या ओळीमुळे समस्या निर्माण होत आहे हे समजून घेण्यासाठी, मला टास्क स्विच ट्रिगर न करता स्टेटमेंटच्या अनुक्रमाद्वारे प्रगती रेकॉर्ड करण्याचा मार्ग शोधणे आवश्यक आहे, जे क्रॅश होण्यापासून प्रतिबंधित करेल. त्यामुळे मला फायदा घेता आला नाही Put_Line()I/O ऑपरेशन्स करणे टाळण्यासाठी. मी काउंटर व्हेरिएबल किंवा तत्सम काहीतरी सेट करू शकतो, परंतु जर मी ते स्क्रीनवर प्रदर्शित करू शकत नाही तर मी त्याचे मूल्य कसे पाहू शकतो?

तसेच, लॉगचे परीक्षण करताना, असे दिसून आले की, हृदयाचे ठोके लटकलेल्या संदेशांची प्रक्रिया असूनही, ज्याने प्रक्रियेच्या सर्व I/O ऑपरेशन्स अवरोधित केल्या आहेत आणि इतर प्रक्रिया करणे प्रतिबंधित केले आहे, इतर स्वतंत्र कार्ये चालविली जात आहेत. म्हणजेच, कार्य पूर्णपणे अवरोधित केले गेले नाही, केवळ कार्यांची (गंभीर) साखळी.

ब्लॉकिंग एक्स्प्रेशनचे मूल्यमापन करण्यासाठी हा संकेत आवश्यक होता.

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

ट्रॅकिंग कार्य फक्त लूपमध्ये चालले आणि ग्लोबल व्हेरिएबलचे मूल्य बदलले आहे की नाही हे पाहण्यासाठी वेळोवेळी तपासले जाते. प्रत्येक बदलासह, मूल्य फाइलमध्ये जतन केले गेले. मग एक छोटी प्रतीक्षा आणि नवीन चेक. मी फाईलमध्ये व्हेरिएबल लिहिले कारण कार्य फक्त तेव्हाच कार्यान्वित केले जाते जेव्हा सिस्टमने ते कार्यान्वित करण्यासाठी निवडले तेव्हा समस्या भागात कार्य स्विच करताना. या कार्यात जे काही घडले त्याचा इतर, असंबंधित अवरोधित कार्यांवर परिणाम होणार नाही.

जेव्हा सिस्टम समस्याप्रधान कोड कार्यान्वित करण्याच्या टप्प्यावर पोहोचेल तेव्हा प्रत्येक पुढील अभिव्यक्तीकडे जाताना ग्लोबल व्हेरिएबल रीसेट केले जाईल अशी अपेक्षा होती. मग काहीतरी घडेल ज्यामुळे टास्क स्विच होईल आणि त्याची अंमलबजावणी वारंवारता (10 Hz) मॉनिटरिंग टास्कच्या तुलनेत कमी असल्याने, मॉनिटर ग्लोबल व्हेरिएबलचे मूल्य कॅप्चर करू शकतो आणि ते लिहू शकतो. सामान्य परिस्थितीत, मला गणनेच्या उपसंचाचा पुनरावृत्ती होणारा क्रम मिळू शकतो: कार्य स्विचच्या वेळी व्हेरिएबलची शेवटची मूल्ये. लटकत असताना, ग्लोबल व्हेरिएबल यापुढे बदलू नये आणि लिहिलेले शेवटचे मूल्य कोणते अभिव्यक्ती पूर्ण झाले नाही हे दर्शवेल.

मी ट्रॅकिंगसह कोड चालवला. तो गोठला. आणि निरीक्षण घड्याळाच्या काट्यासारखे काम केले.

लॉगमध्ये अपेक्षित क्रम आहे, जो म्युटेक्स कॉल केला असल्याचे दर्शविणाऱ्या मूल्याने व्यत्यय आणला होता. Unlock, आणि कार्य पूर्ण झाले नाही - मागील हजारो कॉल्सच्या बाबतीत आहे.

सर्वोच्च अभियंते यावेळी त्यांच्या कोडचे तापाने विश्लेषण करत होते आणि त्यांना म्यूटेक्समध्ये एक जागा सापडली जिथे, सैद्धांतिकदृष्ट्या, लॉक होऊ शकतो. परंतु त्याची संभाव्यता खूपच कमी होती, कारण एका विशिष्ट वेळी घडणाऱ्या घटनांच्या विशिष्ट क्रमामुळेच ब्लॉकिंग होऊ शकते. मर्फीचा कायदा, मित्रांनो, हा मर्फीचा कायदा आहे.

मला आवश्यक असलेल्या कोडच्या तुकड्याचे संरक्षण करण्यासाठी, मी म्युटेक्स फंक्शन कॉल्स (OS म्युटेक्स फंक्शनॅलिटीच्या शीर्षस्थानी तयार केलेले) एका लहान नेटिव्ह अडा म्युटेक्स पॅकेजने त्या तुकड्यावर म्युटेक्स प्रवेश नियंत्रित करण्यासाठी बदलले.

मी ते कोडमध्ये घातले आणि चाचणी चालवली. सात तासांनंतरही कोड काम करत होता.

माझा कोड रॅशनलकडे सबमिट केला गेला, जिथे त्यांनी ते संकलित केले, ते वेगळे केले आणि तपासले की समस्याग्रस्त म्युटेक्स फंक्शन्समध्ये वापरल्या जाणार्‍या दृष्टिकोनाचा वापर केला जात नाही.

माझ्या कारकिर्दीतील हा सर्वात जास्त गर्दीचा कोड रिव्ह्यू होता 🙂 माझ्यासोबत रूममध्ये सुमारे दहा अभियंते आणि व्यवस्थापक होते, आणखी दहा लोक कॉन्फरन्स कॉलवर होते - आणि त्या सर्वांनी सुमारे 20 ओळी कोड तपासले.

कोडचे पुनरावलोकन केले गेले, नवीन एक्झिक्युटेबल फाइल्स एकत्रित केल्या गेल्या आणि औपचारिक प्रतिगमन चाचणीसाठी सबमिट केल्या गेल्या. काही आठवड्यांनंतर, काउंटडाउन चाचणी यशस्वी झाली आणि रॉकेटने उड्डाण केले.

ठीक आहे, हे सर्व चांगले आणि चांगले आहे, परंतु कथेचा मुद्दा काय आहे?

ही एक पूर्णपणे घृणास्पद समस्या होती. कोडच्या शेकडो हजार ओळी, समांतर अंमलबजावणी, एक डझनहून अधिक परस्पर प्रक्रिया, खराब आर्किटेक्चर आणि खराब अंमलबजावणी, एम्बेडेड सिस्टमसाठी इंटरफेस आणि लाखो डॉलर्स खर्च. दबाव नाही, बरोबर.

या समस्येवर काम करणारा मी एकटाच नव्हतो, जरी मी पोर्टिंग करत असताना चर्चेत होतो. पण जरी मी ते केले, याचा अर्थ असा नाही की मला कोडच्या सर्व शेकडो हजारो ओळी समजल्या आहेत किंवा त्या स्किम केल्या आहेत. कोड आणि लॉगचे संपूर्ण देशभरातील अभियंत्यांनी विश्लेषण केले होते, परंतु जेव्हा त्यांनी मला अपयशाच्या कारणांबद्दल त्यांची गृहीते सांगितली तेव्हा त्यांचे खंडन करण्यासाठी मला फक्त अर्धा मिनिट लागला. आणि जेव्हा मला सिद्धांतांचे विश्लेषण करण्यास सांगितले गेले, तेव्हा मी ते दुसर्‍या कोणाला तरी देईन, कारण हे अभियंते चुकीच्या मार्गाने जात आहेत हे माझ्यासाठी स्पष्ट होते. अभिमान वाटतो? होय, हे खरे आहे, परंतु मी दुसर्‍या कारणासाठी गृहितके आणि विनंत्या नाकारल्या.

मला समस्येचे स्वरूप समजले. हे नक्की कुठे होतंय किंवा का होतंय हे मला माहीत नव्हतं, पण काय होतंय ते मला माहीत होतं.

वर्षानुवर्षे, मी भरपूर ज्ञान आणि अनुभव जमा केले आहे. मी अडा वापरण्याच्या प्रवर्तकांपैकी एक होतो आणि त्याचे फायदे आणि तोटे मला समजले. मला माहित आहे की Ada रनटाइम लायब्ररी कार्ये कशी हाताळतात आणि समांतर अंमलबजावणी कशी हाताळतात. आणि मला मेमरी, रजिस्टर्स आणि असेंबलरच्या पातळीवर लो-लेव्हल प्रोग्रामिंग समजते. दुसऱ्या शब्दांत, मला माझ्या क्षेत्रातील सखोल ज्ञान आहे. आणि समस्येचे कारण शोधण्यासाठी मी त्यांचा वापर केला. मी फक्त बगच्या आसपास काम केले नाही, अतिशय संवेदनशील रनटाइम वातावरणात ते कसे शोधायचे हे मला समजले.

संहितेच्या संघर्षाच्या अशा कथा ज्यांना अशा संघर्षाची वैशिष्ट्ये आणि परिस्थिती माहित नाहीत त्यांच्यासाठी फार मनोरंजक नाहीत. परंतु या कथा आपल्याला खरोखर कठीण समस्या सोडवण्यासाठी काय आवश्यक आहे हे समजून घेण्यास मदत करतात.

खरोखर कठीण समस्यांचे निराकरण करण्यासाठी, आपण प्रोग्रामरपेक्षा अधिक असणे आवश्यक आहे. आपल्याला कोडचे "भाग्य" समजून घेणे आवश्यक आहे, ते त्याच्या वातावरणाशी कसे संवाद साधते आणि पर्यावरण स्वतः कसे कार्य करते.

आणि मग तुमचा स्वतःचा उध्वस्त सुट्टीचा आठवडा असेल.

चालू ठेवण्यासाठी

स्त्रोत: www.habr.com