Ada jenis bug yang paling ditakuti pengembang sistem: bug yang tidak ada di kode. Selama bertahun-tahun, satu-satunya cara menanganinya adalah menebak, mempersempit, dan berdoa semoga menemukan pola. Cerita berikut adalah contoh bagaimana satu bug seperti itu akhirnya terkuak, lengkap dengan alat yang tidak lazim: kecerdasan buatan sebagai pencari reproduksi minimal, dengan manusia yang mengarahkan penyelidikan.
Peristiwanya terjadi di dunia LoongArch, arsitektur prosesor yang dikembangkan untuk mendukung ekosistem komputasi mandiri di Tiongkok. Pelakunya adalah erratum, istilah untuk cacat atau perilaku tidak sesuai spesifikasi yang ditemukan pada silikon setelah chip diproduksi. Erratum bukan hal langka. Yang membuat kasus ini menarik adalah bagaimana satu instruksi atomic yang seharusnya menjadi fondasi korektnes program paralel ternyata bisa kehilangan sifat atomiknya.
Berawal dari Paket yang Tidak Selesai Dibangun
Pada Februari 2026, Wang Miao, salah satu pemelihara loong13, menemukan hal aneh saat memaketkan sebuah perangkat lunak matematika bernama normaliz untuk Debian. loong13 sendiri adalah port Debian 13 stable ke LoongArch yang dikelola komunitas. Saat proses pemaketan berjalan, uji bawaan perangkat lunak itu terus kehabisan waktu karena terjebak dalam loop yang tidak bisa keluar.
Menelusuri kode, masalah mengarah ke operasi yang sangat biasa: akumulasi ke variabel bersama memakai konstruksi atomic pada OpenMP. Kondisi keluar loop mensyaratkan nilai hasil akumulasi sama dengan angka tertentu. Kenyataannya nilai hasil akumulasi selalu kurang dari angka itu, sehingga loop tidak pernah berhenti. Karena programnya besar dan kodenya rumit, tim tidak berhasil mempersempit masalah menjadi contoh minimal yang bisa dipahami manusia. Perkara itu pun disimpan.
Perlu dicatat bahwa paket ini tidak bisa dilewati selamanya, karena beberapa paket lain bergantung padanya. Alasan itulah yang membuat investigasi di Februari dilakukan, meskipun akhirnya terhenti tanpa simpulan yang memuaskan.
Enam Bulan Kemudian, Pendekatan yang Berbeda
Pada Agustus, Wang Miao kembali dengan semangat untuk mengangkat perkara lama itu. Kali ini pendekatannya dibalik. Alih-alih manusia yang mencari lokasi masalah, proses pencarian diserahkan ke AI, sementara manusia mengarahkan jalannya penyelidikan. Sekitar dua hari kemudian, sebuah reproducer yang stabil berhasil didapatkan. Dari situ barulah akar masalah muncul: instruksi atomic add pada CPU kadang gagal bersifat atomik.
Di titik itu sifat masalahnya berubah total. Ini bukan lagi bug perangkat lunak pada perangkat lunak matematika. Ini erratum baru pada prosesor, dan menurut catatan penulis, Loongson hanya butuh sekitar dua minggu sejak mengetahuinya untuk menemukan perbaikan yang nyaris tanpa penurunan performa, lalu memberikan firmware uji untuk memverifikasi. Tim mengonfirmasi bahwa firmware uji tersebut mengatasi masalah, dan firmware itu diperkirakan dirilis sebelum 1 Oktober, sehingga pengguna bisa memperbarui firmware untuk menutup masalah tersebut.
Kenapa Masalah Ini Lebih Mudah Muncul di LoongArch
LoongArch memakai model memori lemah. Pada model seperti ini, prosesor dan kompilator diberi keleluasaan lebih besar untuk mengubah urutan akses memori selama hasil akhirnya tetap benar pada program berutas tunggal. Program paralel yang mengandalkan urutan akses tertentu wajib memasang penghalang memori atau memakai operasi sinkronisasi yang benar. Kalau tidak, hasilnya bisa berubah-ubah dan sulit direproduksi.
Sebelum kasus normaliz, tim sudah pernah menemukan kondisi balapan tersembunyi atau masalah urutan memori pada paket lain. Karena itu dugaan awal waktu itu adalah masalah serupa. Dugaan itu wajar: arsitektur dengan model memori lemah memang lebih sering memunculkan gejala seperti ini, sehingga naluri pertama adalah mencurigai kode yang mengasumsikan model memori kuat.
Namun investigasi justru membawa ke arah lain. Gejalanya bukan pola salah baca biasa yang bisa dijelaskan oleh urutan akses yang diubah, melainkan operasi yang dijamin atomik oleh spesifikasi ternyata tidak atomik. Pada arsitektur mana pun, ini adalah pelanggaran janji dasar. Program paralel yang menaruh kepercayaan pada janji itu akan rusak dengan cara yang tampak mustahil: nilainya mundur, atau akumulasi kehilangan satu pembaruan, padahal tidak ada utas lain yang secara logis boleh menimpa nilai tersebut.
Apa Arti Kegagalan Atomic bagi Program
Operasi atomic pada dasarnya adalah perjanjian tingkat perangkat keras: operasi itu berjalan sebagai satu langkah yang tidak bisa disisipi operasi lain terhadap lokasi memori yang sama. Pada akumulasi paralel, perjanjian ini yang membuat setiap pembaruan dihitung tepat sekali. Kalau operasi itu kadang tidak atomik, dua utas bisa membaca nilai lama yang sama, menghitung penambahan masing-masing, lalu menulis hasilnya. Salah satu pembaruan hilang.
Dalam program yang menghitung jumlah objek diskrit, hilangnya satu pembaruan berarti cacat hasil. Dalam program yang memakai nilai itu sebagai syarat kemajuan, seperti yang terjadi pada normaliz, hilangnya pembaruan berarti kondisi keluar tidak pernah tercapai. Loop tidak berhenti bukan karena logikanya salah, melainkan karena dunia tidak memberi angka yang dijanjikan. Inilah bentuk kegagalan yang paling menjengkelkan: bukan kesalahan yang bisa dibaca, melainkan kemandekan yang tidak bisa dijelaskan.
Kenapa Bug Ini Bertahan Berbulan-bulan
Ada beberapa alasan mengapa masalah seperti ini bisa lolos dari perhatian lama. Pertama, frekuensinya rendah. Kalau pelanggaran atomic hanya terjadi sesekali, pengujian biasa bisa lewat dengan mulus. Kedua, ketergantungan pada beban. Kegagalan seperti ini sering muncul hanya ketika banyak utas berjalan bersamaan dengan pola akses tertentu, sehingga mesin dengan jumlah inti atau penjadwalan berbeda bisa berperilaku berbeda. Ketiga, ketergantungan pada biner dan kompilasi. Detail kode mesin yang dihasilkan kompilator dapat menentukan instruksi mana yang akhirnya dipakai, jadi dua build dari sumber yang sama bisa berbeda perilakunya.
Alasan-alasan itu menjelaskan mengapa mempersempit masalah jauh lebih sulit daripada memperbaiki masalah. Menemukan erratum pada dasarnya adalah pekerjaan membuat satu kondisi yang andal menimbulkan gejala. Sebelum reproducer stabil ada, semua hipotesis hanya dugaan yang tidak bisa diuji secara tajam.
Peran AI dalam Investigasi
Bagian yang paling layak digarisbawahi dari kisah ini adalah perubahan metode. Pada ronde pertama, manusia berusaha menemukan jalur dari kode besar ke potongan kecil yang bisa dibaca. Cara itu gagal karena ruang kemungkinan terlalu luas. Pada ronde kedua, pencarian contoh minimal diserahkan ke AI sementara manusia menentukan arah dan menilai hasil. Dalam hitungan hari, reproducer stabil didapat.
Pola ini bukan berarti AI otomatis menyelesaikan masalah. Penulis menegaskan bahwa perannya adalah mengarahkan. Yang berubah adalah biaya untuk mencoba banyak variasi pengurangan kode, sebuah pekerjaan yang melelahkan bagi manusia tetapi relatif murah bagi alat otomatis. Ketika tugasnya adalah menjelajah kombinasi secara mekanis, pembagian kerja antara manusia sebagai pengarah dan mesin sebagai penjelajah terbukti efektif.
Menutup Masalah: Firmware, Bukan Perubahan Program
Karena akar masalahnya ada di silikon, perbaikan yang benar juga datang dari sisi firmware prosesor. Ini poin penting untuk tim yang pernah menghadapi gejala sejenis: tidak semua kemandekan bisa diperbaiki di tingkat aplikasi. Kalau janji atomik dilanggar perangkat keras, tidak ada penulisan ulang kode yang benar-benar memperbaiki keadaan, kecuali kode tersebut sengaja menghindari operasi yang terdampak dengan biaya performa.
Itu juga sebabnya jalur perbaikan melalui firmware lebih disukai. Firmware yang memperbaiki perilaku pada tingkat mesin menyelesaikan masalah untuk semua perangkat lunak sekaligus, tanpa memaksa setiap proyek menambal kodenya sendiri. Menurut catatan penulis, perbaikan itu ditemukan dengan penurunan performa yang sangat kecil, dan firmware ujinya sudah terbukti menyelesaikan masalah pada uji verifikasi. Waktu rilis yang disebut adalah sebelum 1 Oktober 2026.
Pelajaran untuk Tim yang Bekerja di Arsitektur Baru
Beberapa hal bisa ditarik dari kisah ini. Pertama, jangan buru-buru menyalahkan kode sendiri ketika gejalanya tidak masuk akal. Naluri pertama memang mencurigai kondisi balapan pada kode, terutama di arsitektur dengan model memori lemah, dan naluri itu sering benar. Tetapi ketika investigasi menemui jalan buntu yang berkali-kali, hipotesis yang sebelumnya dianggap tidak mungkin, yaitu cacat perangkat keras, justru perlu dipertimbangkan.
Kedua, reproducer stabil adalah segalanya. Selama gejala tidak bisa dibuat muncul dengan andal, setiap perbaikan hanyalah tebakan. Investasi waktu untuk membuat satu contoh minimal sering lebih berharga daripada sepuluh patch yang diuji pada gejala yang tidak terukur.
Ketiga, arsitektur yang masih muda lebih rentan terhadap kejutan. Ekosistem seperti LoongArch sedang membangun fondasi secara cepat, dan kombinasi prosesor, firmware, kompilator, serta pustaka yang semuanya terus berubah memang menciptakan ruang lebih besar bagi masalah yang hanya muncul di lingkungan tertentu. Untuk pekerjaan yang serius, mengikuti catatan erratum resmi dan menjaga jalur pembaruan firmware bukan formalitas, melainkan bagian dari pemeliharaan.
Keempat, transparansi proses investigasi punya nilai tersendiri. Karena penulis menceritakan kronologinya secara terbuka, termasuk bahwa pendekatan pertama gagal, tim lain bisa belajar dari jalannya, bukan hanya dari hasil akhirnya. Itu jauh lebih berguna daripada pengumuman sekilas bahwa ada masalah dan sudah ada perbaikan.
Satu hal yang perlu ditegaskan: pelajaran ini bukan alasan untuk mencurigai perangkat keras setiap kali ada bug aneh. Sebagian besar masalah tetap berada di kode aplikasi. Yang berubah dari kisah ini adalah urutan kecurigaan ketika bukti sudah mengarah ke luar kode, dan kesediaan untuk menguji hipotesis yang tampak tidak mungkin.
Dampak bagi Ekosistem yang Sedang Tumbuh
Kasus ini juga menyoroti rantai ketergantungan yang rapuh di balik satu paket. Normaliz bukan perangkat lunak yang dipakai sendiri. Beberapa paket lain bergantung padanya, sehingga satu kegagalan build menahan pekerjaan di paket-paket turunan. Ketika akar masalahnya ternyata di perangkat keras, setiap paket yang memakai operasi atomic yang dihasilkan kompilator berpotensi terkena, meski gejalanya mungkin berbeda-beda dan tidak selalu berupa loop tanpa akhir.
Karena itu langkah yang wajar bagi tim yang menjalankan beban paralel di perangkat terdampak adalah mengikuti pengumuman firmware dari pembuat chip, lalu menguji ulang beban kerja kritis setelah pemutaran firmware. Sesuai catatan penulis, detail langkah kerja sementara sebelum firmware tersedia dibahas di tulisan aslinya, begitu pula daftar paket yang terdampak dan metodologi pengukurannya. Rujukan resmi itu lebih tepat dipakai sebagai panduan daripada ringkasan sekunder seperti artikel ini.
Kesimpulan
Kisah satu instruksi atomic di LA664 adalah pengingat bahwa lapisan abstraksi yang kita andalkan setiap hari, dari kompilator sampai perangkat keras, kadang menyerahkan pekerjaannya dengan tidak sempurna. Yang menyelamatkan situasi bukan keberuntungan, melainkan kombinasi antara kecurigaan yang terarah, alat yang tepat untuk memperkecil masalah, dan komunikasi yang jujur antara pengguna, komunitas, serta pembuat chip. Perbaikan lewat firmware yang dijanjikan sebelum 1 Oktober 2026 menutup babak ini. Bagi ekosistem yang sedang tumbuh, catatan seperti ini justru aset, karena menunjukkan di mana fondasinya perlu diperkuat.
Rekomendasi Tools & Layanan
Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬