DOOM में वास्तविक हार्डवेयर पर 2.5 साल के लगातार उपयोग के बाद क्रैश होने की पुष्टि

 (lenowo.org)
4 पॉइंट द्वारा GN⁺ 2025-09-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DOOM इंजन में variable overflow के कारण गेम क्रैश होने की पुष्टि हुई
  • वास्तविक उपयोग वाले वातावरण में 2.5 साल तक DOOM चलाने का प्रयोग किया गया
  • variable का मान लगातार बढ़ता रहा और overflow तक पहुँचने पर अनुमानित समय पर गेम बंद हो गया
  • यह प्रयोग PDA और DIY UPS का उपयोग करके लंबे समय तक auto-run वातावरण में किया गया
  • इस टेस्ट ने साबित किया कि सैद्धांतिक समस्या वास्तविक दुनिया में भी सचमुच हो सकती है

प्रयोग की पृष्ठभूमि और प्रेरणा

  • लगभग ढाई साल पहले, DOOM इंजन की संरचना और उसके काम करने के तरीके पर एक लेख पढ़ते समय यह पाया गया कि demo execution tracking में उपयोग होने वाला variable हर demo शुरू होने पर लगातार बढ़ता है
  • इस variable की तुलना पिछले मान से की जाती है, लेकिन मान बार-बार बढ़ते रहने से अंततः overflow का जोखिम मौजूद रहता है
  • सामान्य उपयोग के माहौल में इस overflow स्थिति तक पहुँचना मुश्किल है, लेकिन वास्तव में इसमें कितना समय लगेगा, यह जानने के लिए सीधे प्रयोग करने का फैसला किया गया

प्रयोग की विधि और प्रक्रिया

  • साधारण गणना के आधार पर अनुमान लगाया गया कि overflow होने तक लगभग 2.5 साल का runtime चाहिए होगा
  • वास्तविक पुष्टि के लिए PDA डिवाइस में DOOM इंस्टॉल किया गया और 18650 बैटरी से बने DIY UPS से उसे बिजली दी गई
  • उस डिवाइस को router के USB port से जोड़ा गया, ताकि 5V बिजली की आपूर्ति लगातार बनी रहे
  • सिस्टम को auto-charging वातावरण में लगातार चलने के लिए सेट किया गया और अधिकांश समय उसे ऐसे ही छोड़ दिया गया

क्रैश और परिणाम

  • प्रयोग शुरू होने के लगभग ढाई साल बाद, डिवाइस की स्क्रीन पर popup notification दिखाई दी
  • अनुमान के मुताबिक DOOM overflow के कारण hard crash की स्थिति में चला गया
  • प्रयोग के परिणाम ने साबित किया कि variable overflow के कारण गेम बंद होना वास्तविक हार्डवेयर और वास्तविक software वातावरण में भी हो सकता है

निष्कर्ष और संकेत

  • प्रोग्रामिंग में लंबे समय तक जमा होकर बढ़ने वाले variables के प्रति सावधानी की ज़रूरत पर जोर दिया गया
  • यह प्रयोगात्मक रूप से पुष्टि हुई कि सिर्फ सैद्धांतिक मानी जाने वाली overflow समस्या वास्तविकता में सचमुच फट सकती है
  • legacy code या लंबे समय तक चलने वाले software में छिपे हुए दोषों के प्रति सतर्क रहने की आवश्यकता दिखाई गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-09-18
Hacker News की राय

  • लगभग 1 साल पहले Crash Bandicoot के timer system को देखते समय पता चला कि Crash 3 में int32 type का एक मान लगातार बढ़ता रहता है, और सिर्फ मरने पर reset होता है। अगर इसे 2.26 साल तक चालू छोड़ा जाए तो overflow हो जाता है। तब समय "negative" हो जाता है और गेम कई मज़ेदार तरीकों से टूटने लगता है। इस पर एक वीडियो बनाया गया था YouTube लिंक

    • Final Fantasy 9 में एक खास हथियार पाने के लिए 12 घंटे (यूरोपीय version में 10 घंटे) के भीतर late-game area तक पहुँचना होता है, लेकिन bug की वजह से timer overflow होने तक 2 साल लगातार चालू छोड़ने पर भी इसे पाया जा सकता है। आराम से इंतज़ार करो और लक्ष्य पूरा हो जाएगा। विस्तृत विवरण लिंक

    • हैरानी की बात है कि आपके वीडियो में आपने "crash" पर एक भी pun नहीं किया। freeze को भी crash कहा जा सकता था, तो थोड़ा अफसोस है।

    • यह जानने की उत्सुकता है कि timer tracking के लिए signed integer को default मानना कितना आम था। अगर unsigned होता तो overflow तक समय दोगुना हो जाता, तो ऐसा चुनाव क्यों किया गया होगा यह सवाल है।

    • लगता है बहुत से गेम ऐसे ही बने थे। SotN में भी global timer है। 32-bit system पर कुछ महीनों से लेकर ज़्यादा से ज़्यादा कुछ साल चलने वाले गेम के लिए कोई कई साल बीतने की testing करने की ज़रूरत महसूस नहीं करता था। उस समय किसी ने यह कल्पना नहीं की होगी कि उनके बनाए software को hack, analyze और reverse engineer भी किया जाएगा। हम भी रोज़मर्रा के program लिखते समय ऐसी बातें ज़्यादा नहीं सोचते।

    • यही है असली Time Twister unlock।

  • यह ऐसी स्थिति लगती है जिसे देखकर लगे कि खेलना ही असंभव हो जाएगा। काश कोई इसे ठीक कर दे। Doom वाकई शानदार गेम है और मैं हर कुछ साल में इसे फिर से खेलता हूँ। 2016 reboot मज़ेदार था, लेकिन उसके बाद के titles मुझे व्यक्तिगत रूप से खास पसंद नहीं आए।

    • classic Doom-style gameplay पसंद करने वालों के लिए एक community है r/boomershooters

    • मेरे साथ भी यही है। हाल के titles में metroidvania design और home hub structure वैसा पुराना एहसास नहीं देते। दौड़ो, दुश्मनों को मारो, secrets ढूँढो, और अगले level पर बढ़ो — यह सीधा progression ज़्यादा अच्छा लगता है।

    • मेरी भी यही राय है, खासकर मुझे brutality mode बहुत पसंद है।

    • दिलचस्प बात है कि अब Doom, Quake, StarCraft, WarCraft, Overwatch, Infocom और Sierra के सभी adventure games, और Halo — ये सब Microsoft की मालिकाना संपत्ति हैं। Microsoft 1996 से PC gaming की ज़्यादातर intellectual property पर कब्ज़ा करना चाहता था, तो कह सकते हैं कि उसने लगभग अपना लक्ष्य हासिल कर लिया है।

    • 2016 वाला मेरी नज़र में अब तक का सबसे बेहतरीन single-player FPS था। उसके बराबर अगर कुछ लगा तो सिर्फ Titan Fall 2।

  • यह जानना रोचक होगा कि क्या hardware में overflow trap करने की कोई सुविधा होती है। Doom engine के कामकाज पर एक लेख में पढ़ा था कि demo tracking variable अगला demo शुरू होने के बाद भी बढ़ता रहता है। इस variable की तुलना एक दूसरे variable से की जाती है जो पिछली value को रखता है। असली गेम आखिर crash क्यों हुआ, यह जानने की जिज्ञासा है।

    • C भाषा में signed overflow undefined behavior होता है, इसलिए नतीजा अनुमान से बाहर हो सकता है। लेकिन इस मामले में यह platform या compiler से परे एक जैसा दिख रहा है, इसलिए शायद वजह वह नहीं है। मूल लेख (TFA) के अनुसार यह variable अपनी पिछली value से compare किया जाता है, और code लिखते समय शायद new < old की स्थिति की कल्पना ही नहीं की गई। इससे stack corruption जैसी bug आसानी से आ सकती है। C में, उदाहरण के लिए, अगर return value न रखने वाला function ऐसी स्थिति तक पहुँच जाए जहाँ उसे value लौटानी चाहिए, तो वह भी बिना शोर किए undefined behavior चला देता है।

  • शुक्र मनाना चाहिए कि bug का कारण पहले से पता था। वरना 2.5 साल बाद यह एहसास भी हो सकता था कि "धत्त, debug log चालू करना तो भूल ही गया था।"

  • DOOM, Windows CE से पहले crash हो गया।

    • मैं तो सबसे ज़्यादा इस बात से प्रभावित हूँ कि कोई application 2.5 साल तक PDA पर लगातार चलती रही। आज के नए hardware पर, खासकर internet disconnect होने के बावजूद, ऐसा हो पाएगा या नहीं इस पर बहुत शक है।

    • यह सचमुच कमाल का रिकॉर्ड है।

  • लगता है बहुत ज़्यादा traffic के कारण साइट डाउन हो गई, इसलिए archive.org का लिंक दे रहा हूँ archive.org संग्रहीत लिंक। अफसोस है कि साइट का formatting पूरा नहीं बचा, लेकिन text मौजूद है।

  • 2038 एक दिलचस्प साल होने वाला लगता है।

    • बहुत से लोग 2036 में आने वाली NTP समस्या को नज़रअंदाज़ कर देते हैं। असली पार्टी तो वहीं से शुरू होगी।

    • y2k के दिनों की तुलना में 2038 अब कहीं ज़्यादा नज़दीक महसूस होता है।

    • 64-bit int पर upgrade करने या time_t को long long type में बदलने के लिए 13 साल बचे हैं। बहुत से embedded devices और support से बाहर हो चुके proprietary systems पर अलग से ध्यान देना पड़ेगा। मेरे पास पहले जो SunServer 600MP था, उसके OpenFirmware में भी यही समस्या थी। अच्छा है कि अब वह चिंता की बात नहीं रही।

    • उस समस्या को ठीक करना ही मेरी retirement plan है।

  • इस स्तर की testing मेरे जानने वाले शायद ही कोई tester करते हों। जिस system पर मैं काम करता हूँ, उसमें भी कल सिर्फ 30-second timeout के बाद error handling confirm करने के लिए 5 से ज़्यादा बार इंतज़ार करना पड़ा, और वह बहुत झुंझलाने वाला था।

  • एक समय Windows NT 4 में भी ऐसा ही bug था। यह system uptime मापने वाला high-resolution counter था। Service Pack 3 (या 2) से पहले मैं scheduler से हर महीने की 1 तारीख़ को system reboot करवा देता था। नहीं तो करीब 42 दिन uptime के बाद crash हो जाता था। यानी Microsoft ने भी शायद नहीं सोचा था कि server OS इतना लंबे समय तक लगातार चलता रहेगा।

    • क्या आप इस लिंक में बताए गए issue की बात कर रहे हैं, या NT 4 में कोई अलग bug भी था? यह जानना चाहूँगा।

  • id Software टीम को एक बार फिर सलाम। अगर आज की आम development शैली में यह बनाया गया होता, तो memory fragmentation या memory leak जैसी समस्याओं से 2 साल पूरे होने से पहले ही दम तोड़ देता।