Go 1.6'dan önce, geliştiriciler Go ve C arasında işaretçi geçişi yapabiliyordu; bu da çöp toplayıcının yığın nesnelerini yeniden yerleştirirken C kodunun referansları sakladığı durumlarda geçici çöküşlere yol açıyordu. Bu bellek güvenliği ihlallerini önlemek için, Go 1.6, bir çağrı döndükten sonra C'nin Go işaretçilerini saklamasını yasaklayan katı işaretçi geçiş kuralları tanıttı. Çalışma zamanı, bu kısıtlamaları program çalışması sırasında uygulamak için cgocheck adında bir doğrulama sistemi sağlar.
C kodu, Go çalışma zamanının bellek yönetiminin dışında çalışması anlamına gelir, bu da C'nin tahsis ettiği belleğin kesin çöp toplayıcısına görünmez olduğu anlamına gelir. Eğer C, bir global değişkende veya yığın tahsisinde bir Go nesnesine işaretçi saklarsa ve bu nesne daha sonra GC tarafından taşınırsa (gelecekteki taşınan GC uygulamalarında) ya da Go tarafından ulaşılamaz hale gelirse, o işaretçiyi dereference etmek kullanım sonrası serbest bırakma hatalarına veya veri bozulmasına neden olur. Bunun tespiti, çöp toplama sırasında C belleğini taramayı gerektirir, bu da hesaplama açısından pahalıdır ve standartta üretim ortamlarında uygulanması mümkün değildir.
Çalışma zamanı, üç moda sahip GODEBUG=cgocheck ortam değişkenini sağlar. Mod 1 (varsayılan) C işlevlerine geçirilen argümanların başka Go işaretçileri içermediğini kontrol eder. Mod 2, C yığın ve yığın belleğinin GC sırasında pahalı muhafazakar taramasını etkinleştirir ve bu alanlarda saklanan herhangi bir Go işaretçisi tespit edilirse panik yapar. Mod 0, tüm kontrolleri devre dışı bırakır. Mod 2, her GC döngüsünde C belleğini potansiyel işaretçi kökleri olarak ele alması nedeniyle önemli bir performans yükü (yaklaşık %50 yavaşlama) getirdiğinden varsayılan olarak devre dışı bırakılmıştır.
Yüksek verimli bir mesaj kuyruğu adaptörü oluştururken, C kütüphanesini (librdkafka) sararken, mesaj yüklerini Go'dan C'ye byte dilimlerine geçirip asenkron yığın iletim için göndermemiz gerekiyordu. C kütüphanesi, bu işaretçileri daha sonra arka plan iş parçacıkları tarafından ağ iletimi için kullanılan dahili bağlantılı bir listede kuyrukladı, bu da CGO kuralını ihlal etti; yani C, ilk çağrı döndükten sonra Go işaretçilerini saklayamaz. Yük testleri sırasında, Go GC, altında yatan dizi verilerini geri alırken C hala referanslar tuttuğunda bazen bölümlere ayrılan hatalara neden oldu.
Çözüm 1 - C yığınına kopyala: Her mesaj yükünü, kuyruklamadan önce C.malloc kullanarak C tahsisli belleğe kopyalamayı düşündük, ardından teslim çağrısında serbest bırakmayı planladık. Artılar: Tamamen güvenli, hiç Go işaretçisi saklamaz, herhangi bir Go sürümü ile çalışır. Eksiler: Çift bellek tahsisi (Go'dan C'ye), büyük mesajlar için memcpy'nin CPU maliyeti (1MB+), ve ağ zaman aşımında C geri aramasının tamponu serbest bırakmaması durumunda bellek sızıntısı riski.
Çözüm 2 - cgo.Handle kullanın: Go byte dilimini cgo.Handle içinde (bir tamsayı token) saklamayı ve sadece tanımlayıcıyı C'ye geçirmeyi değerlendirerek, verilerin alınması için bir geri arama gerektiriyoruz. Artılar: Yük için sıfır kopyalama, tür güvenli referans yönetimi ve uzun vadeli C saklama için idiyomatik Go 1.17+ deseni. Eksiler: C kodunda bir geri arama mekanizmasının uygulanmasını gerektirir, veri alımı için ek CGO sınır geçişine bağlı süre gecikmelerini artırır ve C tamamlanma belirtmedikçe tanımlayıcı tablosu sınırsız büyür.
Çözüm 3 - Çalışma zamanı sabitleme (Go 1.21+): runtime.Pinner kullanarak GC'nin byte dilimini taşımaktan veya toplamasından korumayı düşündük. Artılar: C yığını tahsisi olmadan gerçek sıfır kopyalama, doğrudan bellek paylaşımı ve minimum API maliyeti. Eksiler: Go 1.21+ gerektirir, manuel yaşam döngüsü yönetimi (tüm hata yollarında Unpin çağrılmadığında bellek sızıntısı riski) ve sabitlenmiş belleği hata ayıklamak zordur çünkü profillerde kalıcı yığın nesneleri olarak görünür.
Biz, teslim onay geri arama gereksinimini zaten gerektiren adaptör mimarisi nedeniyle cgo.Handle'i (Çözüm 2) seçtik. Bu yaklaşım, veri kopyalamayı ortadan kaldırarak 100MB/s verimlilik gereksinimimizi karşılarken Go sürümleri arasında güvenliği sağladı. Sızıntıları önlemek için hem başarı hem de hata geri aramalarında açık tanımlayıcı silme ekledik.
Sistem, %99.9’luk yüzdelik dilimde 10ms altında kararlı gecikmeler elde etti ve üretimde saniyede 500k’dan fazla mesaj işledi. GODEBUG=cgocheck=2 etkinleştirilerek herhangi bir işaretçi ihlali olmadığını doğrulamak için bir hafta süren stres testlerini geçti. Bellek profilleri, tüm kod yollarındaki uygun temizleme sayesinde tanımlayıcı birikiminden sıfır sızıntı olduğunu doğruladı.
Varsayılan cgocheck=1 modunun, çağrı döndükten sonra C global değişkenlerinde saklanan Go işaretçilerini neden tespit etmekte başarısız olduğunu açıkla?
Varsayılan mod, yalnızca CGO sınırını geçen işaretçi-to-pointer ihlalleri için derhal argümanları ve dönüş değerlerini doğrular; C belleği (global değişkenler, yığın veya yığın) üzerinden saklanan Go işaretçilerini taramaz. Sadece GODEBUG=cgocheck=2, çöp toplama sırasında C belleğinin muhafazakar taramasını etkinleştirerek bu tür saklamaları tespit eder. Bu pahalı kontrol varsayılan olarak devre dışı bırakılmıştır çünkü tüm C belleğini potansiyel GC kökleri olarak ele almayı gerektirir, bu da toplama döngüleri sırasında duraklama sürelerini ve CPU tüketimini önemli ölçüde artırır.
cgo.Handle, C kodu tamsayı tanımlayıcısını saklarken referanslı Go değerinin çöp toplayıcı tarafından geri alınmasını nasıl engeller?
cgo.Handle, içindeki runtime/cgo paketinde tamsayıyı anahtar olarak kullanarak Go değerini içsel bir çalışma zamanı haritasında saklar. Harita değerin bir referansını koruduğundan, çöp toplayıcı, kök taraması sırasında onu erişilebilir olarak işaretler ve belleği geri almaz. C'ye geçirilen tamsayı, işaretçi metadatası içermez, bu nedenle C bunu boyunca herhangi bir müdahalede bulunmadan saklayabilir. C geri arama çağrısı yaptığında veya Go açıkça tanımlayıcıyı sildiğinde, harita girişi kaldırılır, referans düşer ve normal toplanmaya izin verilir.
Fonksiyon çağrısı sırasında bir CGO işaretçi geçişi ihlali gösteren özel panik nedir ve hangi çalışma zamanı bayrağı bunun tespit hassasiyetini değiştirir?
Çalışma zamanı, cgocheck=1 ile bir argümanda Go belleğine işaretçi tespit edildiğinde runtime error: cgo argument has Go pointer to Go pointer hatasını yayar. C belleğinde saklanan işaretçileri de içeren daha kapsamlı tespit için, GODEBUG=cgocheck=2 etkinleştirilmelidir; bu, GC taraması sırasında runtime: cgo result contains Go pointer veya benzeri ölümcül hatalar üretebilir. Bu panikler, C kodunun sözleşmeyi ihlal ettiğini ve çöp toplayıcısı sırasında geçersiz hale gelebilecek Go yönetimli belleğe işaretçiler tutarak veya alarak ihlalde bulunduğunu gösterir.