10% ของการแครชใน Firefox มีสาเหตุมาจากความขัดข้องของฮาร์ดแวร์จากบิตพลิก (bit-flip)

 (mas.to)
2 คะแนน โดย GN⁺ 2026-03-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากผลการวิเคราะห์รายงานการแครชของ Firefox พบว่า ข้อผิดพลาดของฮาร์ดแวร์จากบิตพลิก คิดเป็นสัดส่วนสำคัญของการแครชทั้งหมด
  • ในช่วงสัปดาห์ล่าสุด มีการตรวจพบว่าจาก รายงานการแครชราว 470,000 รายการ มี 25,000 รายการ ที่อาจเป็นกรณีบิตพลิก
  • ยืนยันได้ว่าไม่ใช่บั๊กซอฟต์แวร์ แต่เป็น ความขัดข้องของฮาร์ดแวร์ที่อาจเป็นสาเหตุของการแครชได้สูงสุด 10~15%
  • เครื่องมือทดสอบหน่วยความจำ ที่ทำงานหลังการแครช ใช้เวลาไม่เกิน 3 วินาทีและตรวจสอบได้สูงสุดเพียง 1GiB แต่ก็ยังพบความขัดข้องจริงจำนวนมาก
  • ปัญหานี้ส่งผลต่อ อุปกรณ์ทุกชนิด เช่น PC, สมาร์ทโฟน, เราเตอร์, เครื่องพิมพ์ และสะท้อนข้อจำกัดด้านความน่าเชื่อถือของฮาร์ดแวร์สำหรับผู้บริโภค

การแครชของ Firefox และการตรวจจับบิตพลิก

  • ได้มีการออกแบบวิธีสำหรับตรวจจับปรากฏการณ์ บิตพลิก (bit-flip) จากรายงานการแครชของ Firefox และหลังจากนั้นก็มีการปล่อย เครื่องมือทดสอบหน่วยความจำ ที่จะทำงานอัตโนมัติบนอุปกรณ์ของผู้ใช้หลังเกิดการแครชจริง
    • เครื่องมือนี้จะทำงานบนอุปกรณ์ของผู้ใช้ทันทีหลังเบราว์เซอร์แครช เพื่อตรวจสอบข้อผิดพลาดของหน่วยความจำ
  • จากผลการวิเคราะห์ข้อมูลที่เก็บรวบรวมมา ยืนยันได้ว่า ฮิวริสติกสำหรับตรวจจับบิตพลิกมีประสิทธิภาพ และมีการแครชจำนวนมากที่เกิดจาก หน่วยความจำเสียหรือฮาร์ดแวร์ไม่เสถียร

ผลลัพธ์เชิงสถิติ

  • ในช่วงสัปดาห์ล่าสุด มีรายงานการแครชเข้ามาราว 470,000 รายการ ซึ่งเป็นเพียงบางส่วนของการแครชทั้งหมดเท่านั้น (แบบ opt-in)
    • ในจำนวนนี้ มีประมาณ 25,000 รายการ (ราว 5%) ที่ถูกตรวจจับว่าเป็นการแครชที่อาจเกี่ยวข้องกับบิตพลิก
    • สัดส่วนจริงเป็นเพียงค่าประมาณแบบอนุรักษ์นิยม และ มีความเป็นไปได้ว่าสูงกว่านี้มากกว่า 2 เท่า
  • ในบรรดาการแครชทั้งหมดของ Firefox สูงสุด 10% มีสาเหตุจากความขัดข้องของฮาร์ดแวร์ และหากไม่นับการแครชจากทรัพยากรหมด เช่น หน่วยความจำไม่พอ ตัวเลขนี้จะอยู่ที่ ประมาณ 15%
    • ตัวเลขนี้อาจบิดเบือนได้เล็กน้อย เพราะผู้ใช้ที่มีฮาร์ดแวร์มีปัญหามักจะพบการแครชบ่อยกว่า

ผลการทดสอบหน่วยความจำ

  • เครื่องมือทดสอบหน่วยความจำ ที่ทำงานหลังการแครช สามารถตรวจสอบหน่วยความจำได้สูงสุด 1GiB ภายใน 3 วินาที แต่ก็ยัง ตรวจพบความขัดข้องของฮาร์ดแวร์จริงได้จำนวนมาก
    • ในการแครช 2 กรณีที่คาดว่าเกิดจากบิตพลิก มี 1 กรณีที่ยืนยันพบความขัดข้องจริง
  • แม้การทดสอบจะมีขอบเขตจำกัด แต่ก็แสดงให้เห็นว่า อัตราการเกิดข้อผิดพลาดจริงอยู่ในระดับสูง

ผลกระทบต่อฮาร์ดแวร์โดยรวม

  • ปัญหานี้ส่งผลต่อ อุปกรณ์อิเล็กทรอนิกส์ทุกชนิด ไม่ใช่แค่คอมพิวเตอร์และสมาร์ทโฟน แต่รวมถึงเราเตอร์และเครื่องพิมพ์ด้วย
    • มีรายงานการแครชจำนวนมากแม้กระทั่งในอุปกรณ์อย่าง MacBook ที่ใช้ ARM ซึ่ง RAM ถูกบัดกรีติดอยู่กับแพ็กเกจ CPU
    • การเปลี่ยน RAM ของอุปกรณ์ลักษณะนี้ แทบเป็นไปไม่ได้หากไม่มีอุปกรณ์เฉพาะทางและช่างที่มีทักษะสูง

การพูดคุยในชุมชนและข้อมูลเพิ่มเติม

  • ผู้ใช้บางส่วนได้แบ่งปันกรณีของ RAM ที่มีปัญหา และประสบการณ์การทดสอบด้วย memtest86 พร้อมชี้ให้เห็นถึงการขาดการควบคุมคุณภาพจากผู้ผลิต
  • มีการถกเถียงถึงความจำเป็นของ ECC RAM โดยมีความเห็นว่าแม้เป็นเพียง SECDED ECC ก็สามารถยืดอายุการใช้งานของอุปกรณ์ผู้บริโภคได้อย่างมาก
  • แม้จะมีงานวิจัยเรื่องข้อผิดพลาดของหน่วยความจำในสภาพแวดล้อมเซิร์ฟเวอร์อยู่แล้ว แต่ก็มีการระบุว่า เงื่อนไขแตกต่างจากอุปกรณ์ผู้บริโภค จึงเปรียบเทียบตรง ๆ ได้ยาก
  • จากผลการวิเคราะห์ข้อมูล พบ ความสัมพันธ์อย่างชัดเจนระหว่างอายุการใช้งานของอุปกรณ์กับอัตราการเกิดข้อผิดพลาดของหน่วยความจำ
  • บิตพลิกไม่ได้ทำให้เกิดเพียงการแครชเท่านั้น แต่ยังอาจนำไปสู่ การสูญหายของข้อมูลแบบถาวร เช่น ความเสียหายของไฟล์ซิสเต็ม จึงมีการเน้นย้ำความสำคัญของ ไฟล์ซิสเต็มที่ใช้ checksum เพื่อป้องกันปัญหานี้

บทสรุป

  • เห็นได้อย่างชัดเจนว่าการแครชของ Firefox ในสัดส่วนที่มีนัยสำคัญ ไม่ได้มาจากข้อบกพร่องของซอฟต์แวร์ แต่เกิดจากปัญหาฮาร์ดแวร์
  • สิ่งนี้ทำให้ ความจำเป็นของการตรวจจับข้อผิดพลาดของหน่วยความจำและการใช้ ECC ในอุปกรณ์ผู้บริโภค โดดเด่นยิ่งขึ้น
  • เป็นกรณีตัวอย่างที่แสดงให้เห็นว่าการทำให้ฮาร์ดแวร์มีความน่าเชื่อถือ เชื่อมโยงโดยตรงกับการยกระดับเสถียรภาพของซอฟต์แวร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-06
ความคิดเห็นจาก Hacker News

  • เคยพูดถึงบน HN ไปก่อนหน้านี้แล้ว แต่เพื่อนร่วมงานสมัย ArenaNet ของผม Mike O’Brien (ผู้สร้าง battle.net) ได้ทำ ระบบตรวจจับ bit flip ให้ Guild Wars ราวปี 2004
    ทุกเฟรม (ประมาณ 60FPS) ระบบจะจัดสรรหน่วยความจำแบบสุ่ม รันการคำนวณทางคณิตศาสตร์ แล้วเทียบผลกับตารางค่าอ้างอิง ซึ่งพบว่าประมาณ 1 ใน 1000 เครื่องไม่ผ่าน
    สาเหตุส่วนใหญ่คือ CPU ที่โอเวอร์คล็อก, สถานะหน่วงของหน่วยความจำที่ตั้งผิด, ไฟเลี้ยงไม่พอ, การระบายความร้อนไม่ดี ฯลฯ และเพราะเกมเรนเดอร์ภูมิประเทศกลางแจ้งเยอะ คอมพิวเตอร์เลยมักร้อนเกินไป
    ภายหลังยังพบว่าอาจมีสาเหตุจากปัญหาคุณภาพชิ้นส่วนราคาถูกของ Dell หรือ การโจมตี RowHammer ได้ด้วย
    ผมเคยเขียนโค้ดให้ตอนทดสอบไม่ผ่าน มันจะเปิดเบราว์เซอร์แล้วแสดงหน้าเว็บที่บอกว่า “ไปทำความสะอาดพัดลมคอมพิวเตอร์ของคุณ”

    • ในฐานะนักพัฒนา YouTube บนมือถือ พอดู รายงานแครช ของโค้ดที่ผมรับผิดชอบ บางอันก็ไร้เหตุผลสุด ๆ
      กรณีแบบนี้ผมมักคิดว่าน่าจะมาจาก bit flip แบบสุ่ม หรือฮาร์ดแวร์เสีย
    • ผมไม่เข้าใจว่าทำไม หน่วยความจำ ECC ถึงยังไม่เป็นมาตรฐาน
      มันแพงขึ้นนิดหน่อย แต่แก้ปัญหาแบบนี้ได้แทบทั้งหมด เมนบอร์ดผู้ใช้ทั่วไปบางรุ่นก็รองรับ ECC อยู่แล้ว
    • Guild Wars 1 คือเกมในวัยเด็กของผม
      พ่อแม่ผมชอบเพราะไม่มีค่าสมาชิกรายเดือน และ ระบบบิลด์ 8 สกิล ก็อัจฉริยะมาก
      ถ้ามีภาค 3 ผมอยากให้เพิ่มอิสระในการแสดงออกผ่านบิลด์ให้มากขึ้น
    • ผมเคยอ่านเรื่องนี้มาก่อนใน บล็อก Code of Honor
    • ผมใช้หน่วยความจำ ECC กับ Threadripper 1950x ได้ก็เพราะ เมนบอร์ด ASRock
      ตอนทดสอบโอเวอร์คล็อก ECC ช่วยตรวจจับข้อผิดพลาดเล็ก ๆ ได้ และตั้งแต่นั้นมาก็ไม่เคยเชื่อถือการโอเวอร์คล็อกที่ไม่มี ECC อีกเลย
      โดยเฉพาะ DDR5 ที่ ทำให้เสถียรยากและไวต่อความร้อน มาก จนผมมองว่าการโอเวอร์คล็อกโดยไม่มี ECC แทบเป็นไปไม่ได้

  • หน่วยความจำ ECC ควรกลายเป็นมาตรฐานตั้งแต่ยุคที่ RAM เกิน 1GB แล้ว
    ทุกวันนี้ แรม RGB LED ที่ไร้ประโยชน์กลับถูก แต่ ECC กลับแพง น่าหงุดหงิดมาก

    • ปัญหาใหญ่กว่าตัว ECC คือการหา CPU และเมนบอร์ดที่รองรับ ยากกว่า
      AMD ยังพอมี “รองรับบางส่วน” ใน CPU ผู้ใช้ทั่วไป แต่ Intel อนุญาตเฉพาะระดับเวิร์กสเตชัน
    • DDR5 มี ฟังก์ชันแก้ไขข้อผิดพลาดในตัว อยู่แล้วโดยพื้นฐาน
      แต่ก็ยังไม่แน่ชัดว่ามันเชื่อถือได้กว่า DDR4 ที่ไม่มี ECC หรือไม่
    • ผมคิดว่าต้นตอของปัญหานี้จริง ๆ คือ นโยบายของ Intel
    • แทบไม่เคยเห็นหน่วยความจำ ECC ในโน้ตบุ๊กเลย
      ถ้าเป็นไปได้ผมก็อยากใช้โน้ตบุ๊กที่มี ECC
    • ECC ตามธรรมเนียมแล้วช้ากว่า ซับซ้อนกว่า และไม่ได้กำจัดปัญหาได้หมด
      แต่ในสภาพแวดล้อมแบบเซิร์ฟเวอร์ที่ไฟเลี้ยงและอุณหภูมิเสถียร มันช่วย ป้องกันข้อผิดพลาดได้ 99%

  • ทีม Go ได้นำ ระบบรายงานแครชแบบอิง telemetry มาใช้
    พวกเขาใช้ runtime.SetCrashOutput เพื่อเก็บสแตก goroutine ตอนแครช และจับบั๊กได้หลายร้อยตัว
    แต่รายงานบางส่วนก็อธิบายไม่ได้ เหมือน หน่วยความจำเสียหาย หรือ CPU ทำงานผิดพลาด
    เพราะผู้ใช้โน้ตบุ๊กส่วนใหญ่ใช้ หน่วยความจำที่ไม่มี ECC จึงสรุปได้ว่าน่าจะเป็นความบกพร่องของฮาร์ดแวร์

    • bit flip ส่งผลกับตัวโค้ดเองได้ด้วย ดังนั้นจึง ยากจะเชื่อถือผล telemetry ได้เต็มที่
    • ถ้าเพิ่ม ข้อมูลอุณหภูมิ CPU ลงในรายงาน ก็น่าจะช่วยกรองฮาร์ดแวร์ที่ร้อนเกินไปออกได้
    • ในแอป iOS ก็เคยมี แครชที่อธิบายไม่ออก เป็นครั้งคราว ซึ่งอาจเป็น bit flip บน iPad เก่าก็ได้
    • ผมเองก็กำลังพยายามโน้มน้าวหัวหน้าให้นำ telemetry ที่เน้นแครช มาใช้ในระบบโปรดักชัน

  • ผมอยากแชร์ กรณี bit flip จากบล็อก JuliaLang ด้วย

  • ข้ออ้างว่า “10% ของแครชใน Firefox เกิดจากฮาร์ดแวร์เสีย” ฟังดูแรงเกินไปหน่อย
    บนเบราว์เซอร์สาย Chromium มันไม่ได้แครชบ่อยขนาดนั้น

    • สัญชาตญาณอาจผิดก็ได้
      ที่ Chrome เสถียรกว่า อาจเป็นเพราะมันจัดการ บั๊กซอฟต์แวร์ ในอีก 90% ที่เหลือได้ดีกว่าก็ได้
      หรืออาจหมายความว่าแครชส่วนใหญ่ของ Firefox เป็น ปัญหาซอฟต์แวร์ ก็ได้
    • การที่ 10% ของแครชเป็นแบบนั้น ไม่ได้แปลว่า ผู้ใช้ทุกคนจะโดนเท่ากัน
    • Firefox ของผมแทบไม่เคยล้มเลย เปิดหลายสิบแท็บทิ้งไว้เป็นสัปดาห์ก็ไม่มีปัญหา
    • ผู้ใช้ที่ฮาร์ดแวร์แย่อาจมีแนวโน้มส่ง รายงานแครชเพิ่ม มากกว่า
    • ผมไม่ได้เห็น Firefox หรือ Chrome แครชมาหลายเดือนแล้ว แนะนำให้ลอง stress test ฮาร์ดแวร์ดู

  • ผมเห็นโพสต์ที่บอกว่า “มั่นใจว่า bit flip คือสาเหตุ” แต่ อธิบายวิธีตรวจจับไม่มากพอ

    • น่าจะเป็นวิธีแบบ memtest86 คือเขียนแพตเทิร์นลงหน่วยความจำแล้วอ่านกลับมาเทียบ
      memory_test.rs ในซอร์สโค้ด Mozilla ก็ดูเหมือนจะทำหน้าที่แบบนั้น
    • มีการกล่าวไว้จริงว่า “รันการทดสอบหน่วยความจำหลังเบราว์เซอร์แครชบนเครื่องผู้ใช้”
    • สุดท้ายแล้วดูเหมือนพวกเขาไม่ได้ตรวจจับ bit flip โดยตรง แต่สังเกต แครชที่เกิดจากหน่วยความจำไม่เสถียร มากกว่า
    • กรณีทั่วไปคือ segfault จากข้อผิดพลาดบิตเดียว เช่น มีเพียงหนึ่งบิตของ pointer ที่ผิดไป

  • ผมเพิ่งซื้อพีซีใหม่แล้วโอเวอร์คล็อก RAM ไปที่ 5800MHz จากนั้น Fedora ก็เริ่มค้างแปลก ๆ และแอปเปิดไม่ขึ้น
    พอรัน memtest ได้แค่ 2 นาที ข้อผิดพลาดสีแดง ก็ขึ้นรัว ๆ และพอลดความเร็วลงมา 5200 ก็เสถียร
    จังหวะมันพอดีมากที่มาเห็นโพสต์แบบนี้บนหน้าแรก HN

  • น่าแปลกใจที่อัตราแครชของ Firefox สูงกว่าที่คิด
    ผมเจอ แครชตอนปิดโปรแกรม มาหลายปีแล้ว และส่งรายงานทุกครั้ง
    ส่วนขยายก็เป็น WebExtension ทั้งหมด แต่สาเหตุกลับออกมาหลากหลาย
    Firefox จัดการ หลายหน้าต่างและแท็บ ได้ดี แต่เรื่องเสถียรภาพยังควรปรับปรุง

    • แครชตอนปิดโปรแกรมอาจเป็นผลจาก หน่วยความจำเสียหาย ก็ได้
      เพราะขั้นตอนปิดโปรแกรมจะมีการคืนหน่วยความจำจำนวนมาก ทำให้ bit flip โผล่ออกมาง่าย
      ถ้าอยากยืนยันสาเหตุ ก็ควรลองทดสอบหน่วยความจำดู
    • ถ้าเป็นไปได้ มีคนขอให้แชร์ลิงก์รายงานจาก about:crashes

  • ดีใจที่มีคนเก็บข้อมูลแบบนี้จริง ๆ
    ผมคิดว่า ปัญหาหน่วยความจำเสีย เป็นหนึ่งในประเด็นที่ถูกประเมินต่ำที่สุดในวงการคอมพิวเตอร์
    ถ้ามี สรุปแบบ technical whitepaper สั้น ๆ ก็คงดีมาก