Dukungan Valgrind Ditambahkan ke Go

• Bahasa Go kini secara resmi menambahkan dukungan Valgrind
• Perubahan ini memperkuat kemampuan deteksi error memori dan debugging
• Developer kini dapat lebih mudah mendeteksi kebocoran memori dan error akses
• Peningkatan kompatibilitas dengan Valgrind membuat pekerjaan porting dan maintenance menjadi lebih efisien
• Evaluasi stabilitas kode Go di berbagai platform menjadi lebih mudah

---

Pentingnya Adopsi Dukungan Valgrind di Go

• Dengan ditambahkannya dukungan Valgrind di Go, developer kini dapat secara resmi memanfaatkan alat pendeteksi error memori
• Perubahan ini memungkinkan identifikasi isu seperti use-after-free, kebocoran memori, dan akses memori yang tidak valid dalam kode Go
• Valgrind telah lama digunakan luas untuk mendeteksi masalah memori di berbagai bahasa, dan bagi komunitas Go ini merupakan perubahan penting untuk memperkuat keandalan dan daya tahan
• Fitur yang ditambahkan ini mempermudah berbagai pekerjaan seperti debugging, verifikasi kualitas, dan evaluasi stabilitas terhadap program Go di berbagai platform
• Pembaruan kali ini terutama berarti bahwa lapisan runtime Go kini menyertakan kode instrumentasi untuk Valgrind

Apa itu Valgrind?

• Valgrind adalah alat pengembangan open-source untuk memeriksa error memori, error thread, kebocoran memori, dan lain-lain
• Alat ini banyak digunakan pada bahasa pemrograman sistem seperti C dan C++, serta memberikan deteksi yang akurat terhadap isu pengelolaan memori

Ringkasan Penambahan Fitur Ini

• Instrumentasi kode yang dihasilkan dari perubahan ini memungkinkan Valgrind melacak secara akurat event yang terkait dengan memori yang dialokasikan secara dinamis di runtime Go
• Developer dapat menjalankan program Go dengan Valgrind untuk secara efektif mendiagnosis potensi masalah memori atau akses pointer yang tidak tepat
• Hasilnya, ada manfaat berupa pemeliharaan kode berkualitas tinggi dan pencegahan isu lebih dini pada infrastruktur atau layanan berbasis Go

Dampak yang Diharapkan dari Perubahan Ini

• Proses deteksi error memori dan peningkatan kualitas kode di proyek Go diperkirakan akan menjadi lebih presisi
• Menjamin kompatibilitas dan keandalan kode Go yang didistribusikan ke berbagai platform diperkirakan akan menjadi lebih mudah

[taptaps]

Kalau lihat postingan tentang bahasa Go, rasanya di komentar selalu ada saja
'Kalau Rust sih tidak begitu', 'Kalau Rust sih tidak perlu begitu' wkwk

[GN⁺]

Komentar Hacker News

• Saya adalah penulis CL tersebut, dan lewat peningkatan ini saya ingin mencoba menyalahgunakan fitur pelacakan inisialisasi memori untuk menguji apakah kode kripto berjalan dalam waktu tertentu (pengujian constant-time), dengan cara yang mirip dengan yang pernah diusulkan agl sekitar 15 tahun lalu dan diterapkan di BoringSSL tautan terkait, karena properti ini memang sangat sulit diuji, ke depannya saya juga berharap ada berbagai efek menarik lain, seperti mengeksplorasi apakah dengan mengaktifkan penggunaan Valgrind di Go kita bisa melacak penanganan memori runtime dengan benar, tetapi saya ingin menegaskan bahwa dukungan ini masih berada pada tahap eksperimental, saya belum bisa 100% yakin semua konfigurasi akan berjalan baik, dan mungkin akan muncul lebih banyak peringatan yang sulit dipahami
  • Saya penasaran apakah ada bagian yang bisa dibantu komunitas dalam pengembangannya
  • Menurut saya ini fitur yang sangat keren, dan semoga ini juga bisa membantu menemukan masalah lain di Go, tetapi saya penasaran apakah alih-alih pelacakan yang rumit, bukankah cukup dengan memasukkan berbagai nilai input ke fungsi kriptografi lalu mengukur waktu eksekusinya secara langsung, dan jika semuanya sama maka bisa dicek apakah sifat constant-time terjamin, misalnya bahkan dalam kondisi Garbage Collection atau noise OS, jika setelah memasukkan berbagai input dan mengukur waktunya hasilnya masih dalam toleransi epsilon, rasanya itu sudah cukup, selain itu beberapa CPU memiliki penghitung percabangan kondisional dan rr debugger memanfaatkannya, jadi mungkin jumlah branching sebelum dan sesudah dekripsi bisa dibandingkan dengan nilai ini (berkaitan dengan argumen dalam tulisan agl bahwa branching harus identik agar constant-time tercapai), dan juga mungkin untuk menambahkan sedikit slack time pada waktu maksimum dari 10 dekripsi pertama lalu menambahkan time padding pada setiap dekripsi berikutnya (misalnya menjalankan noop) agar waktunya dipaksa sama, bahkan bisa juga dipikirkan untuk memasang assert agar program crash jika melebihi batas atas, hanya saja metode ini menjadi sulit jika timing meleset karena OS melakukan descheduling
• Sangat bagus bahwa setelah menambahkan header Valgrind ke tree, alih-alih memakai cgo untuk memanggil berbagai macro client request Valgrind, pendekatan yang dipilih adalah memicu client request dengan langsung mengeluarkan instruksi yang dibutuhkan lewat satu fungsi assembly, pendekatan seperti inilah yang diinginkan dalam toolchain bootstrap, yakni membuat building block seminimal mungkin dan menangani sisanya di tingkat bahasa
  • Kalau tidak memilih cara ini dan menghindari pendekatan lama atau alternatif lain, saya penasaran bagaimana seharusnya dilakukan agar prosesnya tetap sesederhana Go namun dengan performa yang hampir setara, saya rasa pertanyaan seperti ini juga akan terus menjadi pekerjaan rumah ke depan
• Senang melihat rsc masih aktif berkontribusi, terutama karena dia bahkan menambahkan komentar pada commit message, itu sangat mengesankan, makin bertambah usia saya makin merasa pentingnya commit message, kalau hanya menulis hal sederhana seperti "tambahkan valgrind" itu tidak banyak membantu saat nanti diarsipkan
  • rsc benar-benar developer kelas rockstar, belakangan ini dia juga banyak mencoba hal baru seperti memakai AI untuk mengelola issue dan PR, dan saya berharap akan ada cukup banyak hasil dari itu
• Fitur ini hanya efektif jika pengujian diterapkan di semua package, jika tidak maka ia akan tenggelam di antara peringatan yang tidak relevan, karena alasan seperti ini Valgrind sulit dipakai pada kode Python
  • Jika itu benar, maka hal yang sama juga seharusnya berlaku untuk C dan C++, dalam kasus saya, saya memakai Valgrind pada program hibrida Python + Boost C++, dan setelah satu jam mengerjakan file suppressions, saya bisa memakainya tanpa masalah
  • Local LLM sepertinya bisa berguna untuk merapikan dan merangkum informasi yang terlalu banyak, itulah mengapa peran toolchain dengan baterai lengkap seperti Valgrind menjadi sangat penting
  • Saya penasaran apa yang dimaksud dengan "semua package diuji" di lingkungan Go
• Valgrind itu seperti kekuatan super tersembunyi, pada sebagian besar software yang saya tulis, saya menjalankan test case dengan 'make check', lalu menjalankan tes yang sama sekali lagi di lingkungan Valgrind dengan 'make check-valgrind', yang terakhir ini hanya saya pakai di PC pengembang, dengan cara ini saya sering menemukan memory leak atau bug yang halus
  • Sebagian saya setuju, tetapi begitu masuk ke multithreading (bagian yang banyak dipakai Go), layer abstraksi Valgrind tidak bekerja terlalu baik, setidaknya berdasarkan saat terakhir saya cukup mendalaminya dengan kode C++, karena memakai scheduler sendiri, masalah concurrency dan race condition dalam situasi nyata tidak terlalu terlihat di Valgrind, dan secara umum penurunan performanya juga cukup besar, meski begitu memang benar bahwa beberapa kali alat ini sangat membantu, jadi saya tetap bersyukur alat ini terus ada
• Dukungan ini benar-benar keren, dan sepertinya akan membuat beberapa bug tambahan terungkap, yang saya penasaran adalah kenapa memilih Valgrind, saya merasa Clang AddressSanitizer (asan) dan MemorySanitizer (msan) bisa menemukan lebih banyak jenis error (misalnya use-after-return), dan juga jauh lebih cepat
  • Go tidak memakai clang/llvm, jadi tool seperti itu tidak bisa diterapkan
  • Go sebenarnya sudah punya dukungan msan/asan sendiri sejak beberapa tahun lalu
  • Valgrind jauh lebih cepat, dan juga bisa dipasang ke program yang sedang berjalan
  • Valgrind juga punya berbagai fungsi seperti pelacakan memori, profiling memori, dan lainnya, jadi dari sudut pandang pelacakan performa juga sangat bagus
• Sangat mengesankan, salah satu isu terbesar di Go adalah profiling serta fenomena memory leak/pressure yang sering terjadi, dan saat ini saya tidak tahu ada alat alternatif yang benar-benar memecahkan masalah ini
  • Saya ingin mendengar lebih detail, issue profiling spesifik seperti apa yang sedang Anda alami? Jika profil memori inuse tidak cukup untuk melacak memory leak (saya penasaran apakah Anda sudah memakai gorefs), mohon jelaskan juga jenis memory pressure seperti apa yang menjadi masalah agar bisa membantu repo goref, sebagai catatan, kami sedang mengerjakan continuous profiling di Datadog dan terus berkontribusi pada profiling runtime Go
  • Saya penasaran bagaimana "memory leak yang persisten" bisa terjadi pada bahasa dengan GC
  • Idealnya, menurut saya seharusnya ada cara untuk secara eksplisit mengontrol apa yang diletakkan di stack seperti di bahasa lain (jangan hanya mengandalkan escape analysis), saat ini terasa merepotkan karena harus menyesuaikannya lewat opsi "-gcflags -m=3" atau pengaturan seperti "ui.codelenses" dan "ui.diagnostic.annotations" di plugin Go VSCode
  • Terkait "memory leak/pressure yang persisten", di Go sebaiknya jangan membuat goroutine kalau tidak tahu pasti bagaimana cara membersihkannya
  • pprof juga sebenarnya bekerja cukup baik, jadi saya penasaran fitur tambahan apa yang Anda inginkan
• Upaya ini terlihat masuk akal, memang ada risiko jika mekanisme client request berubah, tetapi header hampir tidak pernah berubah (terutama saat platform baru ditambahkan), dan Go hanya menangani amd64 dan arm64, jadi masalahnya lebih sedikit, keunggulan sebenarnya dari peningkatan ini bukan sekadar mencegah memory leak melainkan kemampuan menentukan memori yang belum diinisialisasi dengan akurat, karena ketika memori didaur ulang, analisis menjadi sulit jika tidak ada "poisoning" (sengaja ditandai tidak boleh dipakai), fitur ini juga cukup berguna untuk alat lain selain cachegrind dan callgrind
• Bagi saya peningkatan ini terasa bukan sebagai keuntungan, melainkan agak seperti kegagalan kecil bagi ekosistem Go, saya sangat menyukai Valgrind dan sering memakainya saat masih menjadi developer C, tetapi fakta bahwa Go sampai perlu Valgrind terasa seperti ada bagian dari bahasa atau ekosistemnya yang kurang, selama sekitar 6 tahun memakai Rust saya tidak pernah merasa perlu Valgrind sama sekali (selain satu kali dipakai rekan tim), tentu saya tahu kesan ini mungkin muncul karena cgo, tetapi tetap saja sulit menghindari perasaan seperti kemunduran
  • Sulit dipahami kenapa komentar teratas terkait Go selalu menyelipkan sindiran yang menyebut Rust, kesannya makin lama makin defensif sekaligus merasa superior
  • Penggunaan utama fitur ini bukan untuk pelacakan memori yang benar secara umum, melainkan untuk pengujian kode constant-time, sedikit penjelasan tentang itu masih ada di tautan terkait
  • Saya juga pernah sangat sedikit memakai Valgrind di Rust, memang tidak terlalu sering dibutuhkan, tetapi kebutuhannya jelas ada, Rust adalah bahasa yang dipakai di lingkungan yang sangat beragam, dari kode fungsional level tinggi hingga kode mikrokontroler low-level yang mirip C, ada tempat yang sama sekali tidak memakai unsafe dan ada juga yang wajib memakainya, penggunaan C lewat FFI juga umum, jadi pada akhirnya kebutuhan itu bisa muncul, dulu saat membuat modul Rust untuk nginx (ketika belum ada binding resmi/tidak resmi), saya sering melakukan kesalahan dan terbantu oleh valgrind
  • Seberapa sering dipakai akan bergantung pada seberapa banyak kode unsafe yang digunakan, seberapa banyak unsafe crate atau library C/C++ yang dihubungkan, bahkan di Java, .NET, dan Node pun ada kasus di mana alat seperti ini diperlukan karena dependensi eksternal