DOOM dipastikan crash di perangkat keras nyata setelah 2,5 tahun penggunaan terus-menerus

• Terbukti terjadi fenomena game crash akibat overflow variabel pada engine DOOM
• Dilakukan eksperimen menjalankan DOOM selama 2,5 tahun di lingkungan penggunaan nyata
• Saat nilai variabel terus meningkat, ia akhirnya mencapai overflow dan memicu game berhenti pada momen yang diperkirakan
• Eksperimen dilakukan dalam lingkungan eksekusi otomatis jangka panjang menggunakan PDA dan DIY UPS
• Uji ini membuktikan bahwa masalah teoretis memang bisa benar-benar terjadi di dunia nyata

---

Latar belakang dan motivasi eksperimen

• Sekitar dua setengah tahun lalu, saat membaca tulisan tentang struktur dan cara kerja engine DOOM, ditemukan bahwa variabel yang digunakan untuk melacak eksekusi demo terus bertambah setiap kali demo dimulai
• Variabel ini dibandingkan dengan nilai sebelumnya, tetapi karena nilainya terus membesar berulang kali, pada akhirnya ada risiko bawaan terjadinya overflow
• Dalam lingkungan penggunaan biasa, kondisi overflow ini sulit dicapai, tetapi diputuskan untuk menguji sendiri berapa lama waktu yang benar-benar dibutuhkan

Metode dan proses eksperimen

• Melalui perhitungan sederhana, diperkirakan diperlukan sekitar 2,5 tahun runtime sampai overflow terjadi
• Untuk memastikannya secara nyata, DOOM dipasang pada perangkat PDA, lalu dayanya disuplai dengan DIY UPS menggunakan baterai 18650
• Perangkat tersebut dihubungkan ke port USB router untuk menjaga suplai daya 5V secara terus-menerus
• Setelah sistem diatur agar terus berjalan dalam lingkungan pengisian daya otomatis, perangkat itu dibiarkan hampir sepanjang waktu

Terjadinya crash dan hasil

• Sekitar dua setengah tahun setelah eksperimen dimulai, terlihat notifikasi pop-up muncul di layar perangkat
• Sesuai perkiraan, DOOM berpindah ke kondisi hard crash akibat overflow
• Hasil eksperimen ini membuktikan bahwa penghentian game akibat overflow variabel benar-benar dapat terjadi pada perangkat keras nyata dan lingkungan perangkat lunak nyata

Kesimpulan dan implikasi

• Menekankan pentingnya mewaspadai variabel yang terus terakumulasi dan meningkat dalam jangka waktu panjang dalam pemrograman
• Terkonfirmasi secara eksperimental bahwa masalah overflow yang sebelumnya dianggap hanya kemungkinan teoretis benar-benar bisa meledak di dunia nyata
• Menumbuhkan kewaspadaan terhadap cacat tersembunyi pada kode legacy atau perangkat lunak yang berjalan dalam waktu lama

[GN⁺]

Komentar Hacker News

• Sekitar setahun lalu, saat meneliti sistem timer di Crash Bandicoot, ditemukan bahwa di Crash 3 ada nilai bertipe int32 yang terus bertambah dan hanya di-reset saat mati. Jika game dibiarkan menyala selama 2,26 tahun, akan terjadi overflow. Pada titik itu waktunya menjadi "minus" dan game rusak dengan berbagai cara lucu. Sebuah video tentang ini juga dibuat: tautan YouTube

  • Di Final Fantasy 9, untuk mendapatkan senjata tertentu pemain harus mencapai area akhir dalam 12 jam (10 jam di versi Eropa), tetapi karena bug, item itu juga bisa didapat jika game dibiarkan menyala terus selama 2 tahun sampai timernya overflow. Jadi bisa santai menunggu dan tetap mencapai tujuan, tautan penjelasan detail

  • Menarik juga bahwa di videomu tidak ada satu pun permainan kata memakai "crash". Padahal fenomena freeze itu juga bisa saja disebut crash, jadi agak disayangkan.

  • Saya jadi penasaran apakah penggunaan signed integer sebagai default untuk pelacakan timer itu memang umum. Kalau memakai unsigned, waktu sampai overflow setidaknya jadi dua kali lebih lama, jadi saya bertanya-tanya kenapa pilihan itu diambil.

  • Saya rasa banyak game memang dibuat seperti itu. SotN juga punya timer global. Pada sistem 32-bit, untuk game yang dipakai beberapa bulan sampai paling lama beberapa tahun, rasanya tidak ada dorongan untuk menguji berlalunya waktu selama bertahun-tahun. Pada masa itu, tak seorang pun membayangkan software yang mereka buat akan di-hack, dianalisis, dan direkayasa balik. Kita pun biasanya tidak terlalu memikirkan hal seperti itu saat menulis program.

  • Ini benar-benar unlock Time Twister.

• Rasanya ini sudah masuk kategori game menjadi tidak bisa dimainkan, jadi semoga ada yang benar-benar memperbaikinya. Doom memang game yang luar biasa, dan saya selalu kembali memainkannya setiap beberapa tahun. Reboot 2016 juga menyenangkan, tetapi judul-judul setelah itu secara pribadi kurang cocok buat saya.

  • Ada komunitas untuk orang-orang yang lebih suka gameplay bergaya Doom klasik: r/boomershooters

  • Saya juga begitu. Desain metroidvania dan struktur home hub di judul-judul terbaru tidak memberi nuansa yang sama. Saya lebih suka alur sederhana: lari, bunuh musuh, cari rahasia, lalu pindah ke level berikutnya.

  • Saya juga sama, terutama sangat suka mode brutality.

  • Fakta menarik: sekarang Doom dimiliki Microsoft, bersama Quake, StarCraft, WarCraft, Overwatch, semua game petualangan Infocom dan Sierra, serta Halo. Sejak 1996 Microsoft memang ingin menguasai sebagian besar kekayaan intelektual game PC, jadi bisa dibilang tujuan itu hampir tercapai.

  • Versi 2016 adalah single-player FPS terbaik yang pernah saya mainkan. Satu-satunya yang bisa dibandingkan dengannya hanyalah Titan Fall 2.

• Saya penasaran apakah ada fitur di hardware untuk men-trap overflow. Saat membaca tulisan tentang cara kerja engine Doom, saya melihat bahwa variabel pelacak demo terus bertambah bahkan setelah demo berikutnya dimulai. Variabel ini dibandingkan dengan variabel kedua yang menyimpan nilai sebelumnya. Saya ingin tahu kenapa game aslinya sampai crash.

  • Di bahasa C, signed overflow adalah undefined behavior, jadi hasilnya tidak bisa diprediksi. Tetapi dalam kasus ini tampaknya bukan itu, karena kejadiannya sama terlepas dari platform atau compiler. Menurut artikel utama (TFA), variabel ini dibandingkan dengan nilainya sebelumnya, dan kode ditulis tanpa membayangkan situasi new < old bisa terjadi. Karena itu, bug seperti kerusakan stack bisa dengan mudah muncul. Di C, misalnya, jika eksekusi mencapai kondisi ketika sebuah fungsi yang tidak punya nilai return seharusnya mengembalikan nilai, bahasa ini dengan santai menjalankan undefined behavior.

• Patut bersyukur mereka sudah tahu penyebab bug-nya sebelumnya. Bisa saja setelah 2,5 tahun baru sadar, "sial, saya lupa menyalakan debug log".

• DOOM crash lebih dulu daripada Windows CE.

  • Yang paling membuat saya takjub justru aplikasi di PDA itu bisa terus berjalan selama 2,5 tahun. Saya sangat ragu hal seperti ini masih mungkin dilakukan di hardware modern dalam keadaan internet terputus.

  • Rekor yang benar-benar luar biasa.

• Situsnya sepertinya down karena terlalu banyak akses, jadi saya bagikan tautan archive.org: tautan salinan archive.org. Sayangnya format situsnya tidak seluruhnya tersimpan, tetapi teksnya masih ada.

• Sepertinya 2038 akan menjadi tahun yang menarik.

  • Banyak orang mengabaikan masalah NTP di 2036. Di situlah pestanya benar-benar dimulai.

  • Tahun 2038 terasa jauh lebih dekat daripada era y2k dulu.

  • Tinggal 13 tahun untuk upgrade ke int 64-bit atau mengganti time_t menjadi tipe long long. Banyak perangkat embedded dan sistem tertutup yang sudah tidak didukung akan butuh perhatian khusus. OpenFirmware di SunServer 600MP yang dulu saya pakai juga punya masalah yang sama. Untungnya sekarang itu bukan sesuatu yang perlu saya khawatirkan lagi.

  • Menyelesaikan masalah itu adalah rencana pensiun saya.

• Pengujian di level seperti ini rasanya tidak akan dilakukan oleh tester mana pun yang saya kenal. Bahkan di sistem tempat saya bekerja, kemarin saja saya harus menunggu lebih dari 5 kali hanya untuk memeriksa penanganan error setelah timeout 30 detik, dan itu sangat menjengkelkan.

• Dulu Windows NT 4 juga pernah punya bug serupa. Itu terkait counter presisi tinggi untuk mengukur uptime sistem. Sebelum Service Pack 3 (atau 2), kami menjadwalkan reboot sistem setiap tanggal 1 tiap bulan. Kalau tidak, sistem akan crash setelah uptime sekitar 42 hari. Bahkan Microsoft pun tampaknya tidak membayangkan OS server akan dibiarkan berjalan selama itu.

  • Apakah yang dimaksud mungkin isu yang disebut di tautan ini, atau memang ada bug terpisah di NT 4? Saya penasaran.

• Sekali lagi salut untuk tim id Software. Kalau dikembangkan dengan cara yang umum sekarang, mungkin game itu sudah mati jauh sebelum 2 tahun karena fragmentasi memori atau memory leak.