10% crash Firefox disebabkan cacat perangkat keras akibat bit flip

 (mas.to)
2 poin oleh GN⁺ 2026-03-06 | 1 komentar | Bagikan ke WhatsApp
  • Hasil analisis laporan crash Firefox menunjukkan bahwa kesalahan perangkat keras akibat bit flip menyumbang porsi signifikan dari seluruh crash
  • Dalam satu minggu terakhir, sekitar 25 ribu dari 470 ribu laporan crash terdeteksi sebagai kasus yang kemungkinan melibatkan bit flip
  • Terbukti bahwa bukan bug software, melainkan cacat perangkat keras yang menjadi penyebab hingga 10–15% crash
  • Alat uji memori yang berjalan setelah crash memeriksa hingga 1GiB dalam waktu kurang dari 3 detik, tetapi tetap menemukan banyak cacat nyata
  • Masalah ini memengaruhi semua jenis perangkat seperti PC, smartphone, router, dan printer, serta menyoroti batas keandalan perangkat keras konsumen

Deteksi crash Firefox dan bit flip

  • Sebuah metode dirancang untuk mendeteksi fenomena bit flip dalam laporan crash Firefox, lalu alat uji memori yang otomatis berjalan setelah crash didistribusikan ke perangkat pengguna nyata
    • Alat ini berjalan di perangkat pengguna segera setelah browser crash untuk memeriksa kesalahan memori
  • Hasil analisis data yang terkumpul menunjukkan bahwa heuristik deteksi bit flip ini efektif, dan banyak crash terjadi pada memori rusak atau perangkat keras yang tidak stabil

Hasil statistik

  • Sekitar 470 ribu laporan crash diterima selama seminggu terakhir, dan ini hanya mencakup sebagian dari seluruh crash dengan skema opt-in
    • Dari jumlah tersebut, sekitar 25 ribu kasus (sekitar 5%) terdeteksi sebagai crash yang kemungkinan melibatkan bit flip
    • Angka sebenarnya adalah estimasi konservatif, dan kemungkinan nyata bisa lebih dari dua kali lipat
  • Dari seluruh crash Firefox, hingga 10% disebabkan cacat perangkat keras, dan jika crash akibat kehabisan sumber daya seperti kekurangan memori dikecualikan, angkanya mencapai sekitar 15%
    • Angka ini bisa agak terdistorsi karena pengguna dengan perangkat keras bermasalah lebih sering mengalami crash

Hasil uji memori

  • Alat uji memori yang dijalankan setelah crash memeriksa hingga 1GiB memori dalam waktu kurang dari 3 detik, tetapi berhasil mendeteksi banyak cacat perangkat keras nyata
    • Dalam satu dari dua crash yang diduga akibat bit flip, cacat nyata benar-benar terkonfirmasi
  • Walaupun cakupan pengujiannya terbatas, hasil ini menunjukkan bahwa tingkat kesalahan nyata cukup tinggi

Dampak di seluruh perangkat keras

  • Masalah seperti ini memengaruhi bukan hanya komputer dan smartphone, tetapi juga semua perangkat elektronik seperti router dan printer
    • Banyak crash juga dilaporkan pada perangkat seperti MacBook berbasis ARM yang RAM-nya disolder ke paket CPU
    • Penggantian RAM pada perangkat tersebut tidak mungkin dilakukan tanpa peralatan khusus dan teknisi berpengalaman

Diskusi komunitas dan informasi tambahan

  • Sebagian pengguna membagikan pengalaman tentang kasus RAM rusak dan pengujian memtest86, sambil menyoroti kurangnya kontrol kualitas dari produsen
  • Diskusi tentang perlunya ECC RAM terus berlanjut, dengan pendapat bahwa SECDED ECC saja sudah dapat secara signifikan memperpanjang umur perangkat konsumen
  • Disebutkan bahwa memang ada riset tentang kesalahan memori di lingkungan server, tetapi kondisinya berbeda dari perangkat konsumen sehingga sulit dibandingkan secara langsung
  • Hasil analisis data mengonfirmasi adanya korelasi kuat antara penuaan perangkat dan tingkat terjadinya kesalahan memori
  • Bit flip tidak hanya menyebabkan crash, tetapi juga dapat berujung pada kehilangan data permanen seperti kerusakan filesystem, sehingga pentingnya filesystem berbasis checksum ikut ditekankan

Kesimpulan

  • Terlihat jelas bahwa porsi besar crash Firefox berasal dari masalah perangkat keras, bukan cacat software
  • Hal ini menyoroti pentingnya deteksi kesalahan memori dan penerapan ECC pada perangkat konsumen
  • Ini adalah contoh yang menunjukkan bahwa memastikan keandalan perangkat keras berhubungan langsung dengan peningkatan stabilitas software

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-06
Komentar Hacker News

  • Saya pernah menyebut ini di HN sebelumnya, tetapi Mike O’Brien (pencipta battle.net), rekan saya saat di ArenaNet, sekitar tahun 2004 membuat sistem pendeteksi bit flip untuk Guild Wars
    Pada setiap frame (sekitar 60 FPS), sistem itu mengalokasikan memori acak, menjalankan operasi matematika, lalu membandingkan hasilnya dengan tabel nilai acuan, dan sekitar 1 dari 1000 mesin gagal
    Penyebabnya kebanyakan CPU yang dioverclock, timing memori yang salah, daya listrik yang kurang, pendinginan yang buruk, dan sebagainya, serta game itu sering membuat komputer overheat karena banyak merender medan luar ruangan
    Belakangan diketahui bahwa masalah kualitas komponen murah dari Dell atau serangan RowHammer juga bisa menjadi penyebab
    Saya menulis kode yang saat tes gagal akan membuka browser dan menampilkan halaman yang menyuruh pengguna “membersihkan kipas komputer”

    • Sebagai pengembang YouTube mobile, saat melihat laporan crash dari kode yang saya tangani, sebagian benar-benar tidak masuk akal
      Dalam kasus seperti ini, saya biasanya menganggap penyebabnya adalah bit flip acak atau hardware yang rusak
    • Saya tidak paham kenapa memori ECC masih belum menjadi standar
      Memang sedikit lebih mahal, tetapi hampir menyelesaikan semua masalah seperti ini. Beberapa motherboard konsumen juga sudah mendukung ECC
    • Guild Wars 1 adalah game masa kecil saya
      Orang tua saya menyukainya karena tidak ada biaya langganan bulanan, dan sistem build 8-skill benar-benar jenius
      Kalau ada seri ketiga, saya berharap kebebasan mengekspresikan build dibuat lebih tinggi lagi
    • Saya pernah membaca cerita ini dulu di blog Code of Honor
    • Berkat motherboard ASRock, saya bisa memakai memori ECC di Threadripper 1950x
      Saat menguji overclock, ECC membantu mendeteksi error halus, dan sejak itu saya sama sekali tidak lagi percaya pada overclock tanpa ECC
      DDR5 khususnya sulit distabilkan dan sensitif terhadap panas, jadi menurut saya overclock tanpa ECC praktis mustahil

  • Memori ECC seharusnya sudah menjadi standar sejak kapasitas melewati 1 GB
    Sekarang saya kesal karena memori RGB LED yang tidak berguna justru murah, sementara ECC mahal

    • Dibanding ECC itu sendiri, yang lebih sulit adalah mencari CPU dan motherboard yang mendukungnya
      AMD setidaknya “mendukung sebagian” ECC di CPU konsumen, tetapi Intel hanya mengizinkannya di kelas workstation
    • DDR5 pada dasarnya memiliki fitur koreksi error bawaan
      Namun belum jelas apakah itu lebih andal dibanding DDR4 tanpa ECC
    • Saya rasa akar masalah ini adalah kebijakan Intel
    • Saya hampir tidak pernah melihat memori ECC di laptop
      Kalau memungkinkan, saya ingin memakai laptop dengan ECC
    • ECC secara tradisional lebih lambat dan lebih rumit, serta tidak menghilangkan masalah sepenuhnya
      Namun di lingkungan server dengan kondisi daya dan suhu yang stabil, ECC mencegah 99% error

  • Tim Go telah memperkenalkan sistem laporan crash berbasis telemetri
    Dengan runtime.SetCrashOutput, mereka mengumpulkan stack crash goroutine dan berhasil menangkap ratusan bug
    Tetapi sebagian laporan ada yang tidak bisa dijelaskan, seperti korupsi memori atau CPU yang malfungsi
    Karena sebagian besar pengguna laptop memakai memori tanpa ECC, mereka menilai kemungkinan besar penyebabnya adalah cacat hardware

    • Bit flip juga memengaruhi kode itu sendiri, jadi bahkan hasil telemetri pun sulit dipercaya
    • Jika informasi suhu CPU ditambahkan ke laporan, mungkin hardware yang overheat bisa difilter
    • Di aplikasi iOS juga kadang ada crash yang tidak bisa dipahami, dan mungkin itu bit flip pada iPad lama
    • Saya juga sedang berusaha meyakinkan atasan untuk menerapkan telemetri yang berfokus pada crash di production

  • Saya juga ingin membagikan kasus bit flip di blog JuliaLang

  • Klaim bahwa “10% crash Firefox disebabkan oleh cacat hardware” terdengar terlalu berani
    Di browser berbasis Chromium, crash tampaknya tidak sesering itu

    • Intuisi bisa saja salah
      Bisa jadi Chrome lebih stabil karena lebih baik dalam menangani 90% sisanya, yaitu bug software
      Justru mungkin itu berarti sebagian besar crash Firefox adalah masalah software
    • Walaupun 10% crash seperti itu, bukan berarti hal itu berlaku sama untuk semua pengguna
    • Firefox saya hampir tidak pernah crash. Membuka puluhan tab dan membiarkannya berjalan berminggu-minggu juga tidak masalah
    • Pengguna dengan hardware buruk mungkin akan mengirim lebih banyak crash tambahan
    • Saya sudah berbulan-bulan tidak melihat Firefox atau Chrome crash. Saya sarankan melakukan stress test pada hardware

  • Saya melihat tulisan yang mengatakan “saya yakin penyebabnya adalah bit flip”, tetapi penjelasan tentang cara mendeteksinya kurang

    • Mungkin caranya seperti memtest86, yaitu menulis pola ke memori lalu membacanya kembali untuk dibandingkan
      memory_test.rs di source code Mozilla tampaknya juga melakukan peran seperti itu
    • Memang ada disebutkan bahwa mereka “menjalankan tes memori di PC pengguna setelah browser crash”
    • Pada akhirnya, tampaknya mereka bukan mendeteksi bit flip secara langsung, melainkan mengamati crash akibat memori yang tidak stabil
    • Kasus umum adalah segfault akibat error satu bit, misalnya saat hanya satu bit pada pointer yang salah

  • Saya membeli PC baru dan meng-overclock RAM ke 5800 MHz, lalu Fedora mulai hang aneh dan aplikasi tidak mau berjalan
    Setelah menjalankan memtest, dalam 2 menit error merah langsung bermunculan, dan saat kecepatannya diturunkan ke 5200 sistem menjadi stabil
    Kebetulan sekali melihat tulisan seperti ini di halaman depan HN

  • Saya terkejut rasio crash Firefox ternyata lebih tinggi dari yang saya kira
    Selama bertahun-tahun saya terus mengalami crash saat keluar, dan setiap kali selalu mengirim laporan
    Walaupun semua ekstensi adalah WebExtension, penyebab yang muncul tetap beragam
    Firefox cukup bagus menangani banyak jendela dan tab, tetapi stabilitasnya masih perlu ditingkatkan

    • Crash saat keluar bisa jadi merupakan akibat dari korupsi memori
      Karena banyak memori dibebaskan selama proses keluar, bit flip lebih mudah terlihat
      Untuk memastikan penyebabnya, sebaiknya lakukan tes memori
    • Jika memungkinkan, ada yang meminta untuk membagikan link laporan dari about:crashes

  • Senang melihat ada yang benar-benar mengumpulkan data seperti ini
    Saya rasa masalah memori rusak adalah salah satu isu paling diremehkan dalam komputasi
    Akan bagus jika ada ringkasan singkat berbentuk white paper teknis