Firefox क्रैश के 10% हार्डवेयर खराबी से होने वाले bit-flip के कारण

 (mas.to)
2 पॉइंट द्वारा GN⁺ 2026-03-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Firefox क्रैश रिपोर्ट के विश्लेषण से पता चला कि bit-flip से होने वाली हार्डवेयर त्रुटियां कुल क्रैश का एक बड़ा हिस्सा हैं
  • पिछले एक हफ्ते में लगभग 4.7 लाख क्रैश रिपोर्ट्स में से 25 हजार ऐसे मामलों के रूप में पहचानी गईं जिनमें bit-flip की संभावना थी
  • यह पुष्टि हुई कि सॉफ्टवेयर बग नहीं बल्कि हार्डवेयर खराबी अधिकतम 10~15% क्रैश का कारण है
  • क्रैश के बाद चलने वाला memory test tool 3 सेकंड के भीतर अधिकतम 1GiB ही जांचता है, फिर भी यह कई वास्तविक खराबियां ढूंढ लेता है
  • यह समस्या PC, स्मार्टफोन, router, printer जैसे सभी डिवाइसेज़ को प्रभावित करती है और consumer hardware reliability की सीमाएं दिखाती है

Firefox क्रैश और bit-flip detection

  • Firefox क्रैश रिपोर्ट्स में bit-flip घटना का पता लगाने के लिए एक तरीका तैयार किया गया, और बाद में एक memory test tool वितरित किया गया जो वास्तविक यूज़र डिवाइसेज़ पर क्रैश के बाद अपने-आप चलता है
    • यह टूल ब्राउज़र क्रैश के तुरंत बाद यूज़र के डिवाइस पर चलकर memory errors की जांच करता है
  • एकत्रित डेटा के विश्लेषण से यह पुष्टि हुई कि bit-flip detection heuristic प्रभावी है, और कई क्रैश खराब memory या अस्थिर hardware पर होते हैं

सांख्यिकीय नतीजे

  • पिछले एक हफ्ते में लगभग 4.7 लाख क्रैश रिपोर्ट्स दर्ज हुईं, जिनमें कुल क्रैश का केवल एक हिस्सा शामिल है (opt-in पद्धति)
    • इनमें से लगभग 25 हजार मामले (करीब 5%) bit-flip की संभावना वाले क्रैश के रूप में पहचाने गए
    • वास्तविक अनुपात एक conservative estimate है, और असल में यह दोगुने से भी अधिक हो सकता है
  • सभी Firefox क्रैश में अधिकतम 10% हार्डवेयर खराबी से जुड़े हैं, और memory exhaustion जैसे resource depletion क्रैश हटाने पर यह करीब 15% तक पहुंचता है
    • जिन यूज़र्स के hardware में खराबी होती है, वे अधिक बार क्रैश देखते हैं, इसलिए आंकड़े कुछ हद तक विकृत हो सकते हैं

memory test के नतीजे

  • क्रैश के बाद चलाए गए memory test tool ने 3 सेकंड के भीतर अधिकतम 1GiB memory की जांच की, फिर भी इसने कई वास्तविक hardware defects पकड़े
    • bit-flip माने गए हर दो क्रैश में से एक में वास्तविक खराबी की पुष्टि हुई
  • सीमित दायरे का यह टेस्ट भी दिखाता है कि वास्तविक error rate ऊंचा है

हार्डवेयर पर व्यापक असर

  • यह समस्या कंप्यूटर और स्मार्टफोन ही नहीं, router, printer और अन्य सभी electronic devices को प्रभावित करती है
    • ARM-आधारित MacBook जैसे उन डिवाइसेज़ में भी कई क्रैश रिपोर्ट हुए जिनमें RAM CPU package पर soldered होती है
    • ऐसे डिवाइसेज़ में RAM बदलना विशेष उपकरण और कुशल तकनीशियन के बिना संभव नहीं है

कम्युनिटी चर्चा और अतिरिक्त जानकारी

  • कुछ यूज़र्स ने खराब RAM के मामले और memtest86 टेस्ट के अनुभव साझा किए, और manufacturers की quality control की कमी की ओर इशारा किया
  • ECC RAM की जरूरत पर चर्चा हुई, और यह राय सामने आई कि केवल SECDED ECC भी consumer devices की उम्र को काफी बढ़ा सकता है
  • server environments में memory errors पर शोध मौजूद है, लेकिन कहा गया कि consumer device environments की परिस्थितियां अलग हैं, इसलिए सीधी तुलना कठिन है
  • डेटा विश्लेषण से डिवाइस की उम्र बढ़ने और memory error rate के बीच मजबूत संबंध की पुष्टि हुई
  • bit-flip सिर्फ क्रैश ही नहीं बल्कि filesystem corruption जैसे स्थायी data loss का कारण भी बन सकता है, इसलिए checksum-आधारित filesystem के महत्व पर जोर दिया गया

निष्कर्ष

  • यह स्पष्ट रूप से सामने आया कि Firefox क्रैश का एक बड़ा हिस्सा software defects नहीं बल्कि hardware problems से आता है
  • consumer devices में memory error detection और ECC अपनाने की जरूरत उभरकर सामने आई
  • यह मामला दिखाता है कि hardware reliability सुनिश्चित करना software stability सुधारने से सीधे जुड़ा है

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

1 टिप्पणियां

 
GN⁺ 2026-03-06
Hacker News की टिप्पणियाँ

  • मैंने यह बात पहले भी HN पर कही थी, लेकिन ArenaNet के दिनों में मेरे सहकर्मी Mike O’Brien (battle.net के निर्माता) ने लगभग 2004 में Guild Wars के लिए एक bit-flip detection system बनाया था
    हर फ्रेम पर (लगभग 60FPS) वह random memory allocate करके गणितीय ऑपरेशन चलाता था और परिणामों की तुलना reference value table से करता था, और लगभग 1000 में से 1 मशीन इसमें fail हो जाती थी
    ज़्यादातर कारण overclocked CPU, गलत memory timing, अपर्याप्त power, खराब cooling वगैरह थे, और गेम में outdoor terrain rendering बहुत होने से कंप्यूटर अक्सर overheat हो जाते थे
    बाद में पता चला कि Dell के low-cost parts की quality issue या RowHammer attack भी कारण हो सकते हैं
    मैंने test fail होने पर browser खोलकर “अपने कंप्यूटर के fan साफ करें” वाला पेज दिखाने के लिए code लिखा था

    • YouTube mobile developer के रूप में, जिन crash reports वाले codebase पर मैं काम करता था उनमें कुछ crash बिल्कुल समझ से बाहर होते थे
      ऐसे मामलों में मुझे अक्सर लगता था कि वजह random bit flips या खराब hardware है
    • मुझे समझ नहीं आता कि ECC memory अभी तक standard क्यों नहीं बनी
      यह थोड़ी महंगी है, लेकिन ऐसे लगभग सभी issues हल कर देती है। कुछ consumer motherboards पहले से ECC support करते हैं
    • Guild Wars 1 मेरे बचपन का गेम था
      monthly subscription न होने से मेरे माता-पिता खुश थे, और 8-skill build system सच में कमाल का था
      अगर तीसरा भाग आए, तो build expression की freedom और बढ़नी चाहिए
    • मैंने यह कहानी पहले Code of Honor ब्लॉग पर पढ़ी थी
    • ASRock motherboard की वजह से मैं Threadripper 1950x पर ECC memory इस्तेमाल कर सका
      overclocking test के दौरान ECC की मदद से सूक्ष्म errors पकड़ सका, और उसके बाद से मैंने ECC के बिना overclocking पर कभी भरोसा नहीं किया
      DDR5 में खासकर stability बनाए रखना मुश्किल है और यह heat-sensitive है, इसलिए ECC के बिना overclocking को मैं लगभग असंभव मानता हूँ

  • ECC memory को 1GB पार करते ही standard बन जाना चाहिए था
    आजकल बेकार की RGB LED memory सस्ती मिलती है, लेकिन ECC महंगी है, यह परेशान करने वाली बात है

    • ECC से भी ज़्यादा मुश्किल supported CPU और motherboard ढूँढना है
      AMD कम से कम consumer CPU में ECC को “partial support” देता है, लेकिन Intel इसे सिर्फ workstation-grade पर अनुमति देता है
    • DDR5 में मूल रूप से built-in error correction feature होता है
      लेकिन यह ECC-रहित DDR4 से ज़्यादा reliable है या नहीं, यह स्पष्ट नहीं है
    • मुझे लगता है इस समस्या की जड़ Intel की policy है
    • laptops में ECC memory मैंने लगभग कभी नहीं देखी
      अगर संभव हो, तो मैं ECC वाला laptop इस्तेमाल करना चाहूँगा
    • पारंपरिक रूप से ECC धीमी और जटिल रही है, और यह समस्याओं को पूरी तरह खत्म भी नहीं करती
      लेकिन server environment जैसी स्थिर power और temperature conditions में यह 99% errors को रोकती है

  • Go टीम ने telemetry-based crash reporting system अपनाया है
    runtime.SetCrashOutput के जरिए goroutine crash stack इकट्ठा करके उन्होंने सैकड़ों bugs पकड़े
    लेकिन कुछ reports ऐसे थे जिन्हें memory corruption या CPU malfunction जैसी वजहों के बिना समझाना मुश्किल था
    चूँकि ज़्यादातर laptop users ECC-रहित memory इस्तेमाल करते हैं, इसलिए उन्होंने माना कि hardware fault की संभावना ज़्यादा है

    • bit flip code पर भी असर डाल सकता है, इसलिए telemetry results पर भी भरोसा करना मुश्किल है
    • अगर reports में CPU temperature information जोड़ दी जाए, तो overheating hardware को फ़िल्टर किया जा सकता है
    • iOS apps में भी कभी-कभी समझ से बाहर crashes होते थे, और यह पुराने iPad में bit flip की वजह से हो सकता है
    • मैं भी production में crash-centered telemetry लाने के लिए अपने manager को मनाने की कोशिश कर रहा हूँ

  • मैं JuliaLang ब्लॉग के bit flip case को भी साझा करना चाहूँगा

  • “Firefox crashes का 10% hardware fault की वजह से है” यह दावा कुछ ज़्यादा ही साहसी लगता है
    Chromium-based browsers में तो crash इतनी बार नहीं होते

    • हो सकता है मेरी intuition गलत हो
      Chrome ज़्यादा stable इसलिए हो सकता है क्योंकि बाकी 90% software bugs को handle करने की उसकी क्षमता बेहतर है
      उल्टा इसका मतलब यह भी हो सकता है कि Firefox के ज़्यादातर crashes software problems हैं
    • अगर 10% crashes ऐसे हैं, तो इसका मतलब यह नहीं कि यह हर user पर समान रूप से लागू होता है
    • मेरा Firefox तो लगभग कभी crash नहीं होता। मैं दर्जनों tabs खोलकर उसे कई हफ्तों तक चलाता हूँ और कोई समस्या नहीं होती
    • जिन users का hardware खराब है, वे अतिरिक्त crashes कहीं ज़्यादा भेज सकते हैं
    • कई महीनों से मैंने Firefox या Chrome crash होते नहीं देखा। hardware को stress test करने की सलाह दूँगा

  • मैंने एक पोस्ट देखी जिसमें लिखा था, “हमें यक़ीन है कि वजह bit flip है,” लेकिन यह कैसे detect किया गया, इसकी व्याख्या कमज़ोर थी

    • शायद memtest86 की तरह memory में pattern लिखकर फिर पढ़कर तुलना की गई होगी
      Mozilla source code का memory_test.rs भी शायद यही काम करता है
    • वास्तव में यह भी कहा गया है कि “user के PC पर browser crash होने के बाद memory test चलाया जाता है”
    • आख़िरकार ऐसा लगता है कि इन्होंने bit flip को सीधे detect नहीं किया, बल्कि unstable memory से होने वाले crashes को observe किया
    • जैसे pointer का सिर्फ एक bit गलत हो जाए, single-bit error से होने वाला segfault एक आम उदाहरण है

  • मैंने नया PC खरीदा और RAM को 5800MHz तक overclock किया, तो Fedora अजीब तरह से freeze होने लगा और apps चल ही नहीं रहे थे
    memtest चलाते ही 2 मिनट में लाल errors की बाढ़ आ गई, और speed को 5200 पर लाने के बाद सब stable हो गया
    HN के first page पर यह पोस्ट अभी देखना कमाल की timing है

  • यह देखकर हैरानी होती है कि Firefox का crash rate मेरी अपेक्षा से ज़्यादा है
    मुझे कई सालों से shutdown के समय crash की समस्या लगातार होती रही है, और मैं हर बार report submit करता हूँ
    सभी extensions WebExtension हैं, फिर भी कारण हर बार अलग-अलग दिखता है
    Firefox multiple windows और tabs को संभालने में अच्छा है, लेकिन stability में अभी सुधार की ज़रूरत है

    • shutdown crash शायद memory corruption का नतीजा भी हो सकता है
      shutdown process में बहुत memory free की जाती है, इसलिए bit flip वहाँ ज़्यादा आसानी से सामने आ सकता है
      कारण जानने के लिए memory test चलाना अच्छा रहेगा
    • अगर संभव हो, तो about:crashes की report link साझा करने का अनुरोध है

  • यह देखकर अच्छा लगा कि कोई वास्तव में इस तरह का data इकट्ठा कर रहा है
    मुझे लगता है faulty memory issue computing की सबसे कम आंकी गई समस्याओं में से एक है
    इस पर एक छोटी technical whitepaper-style summary होनी चाहिए