Go utrzymuje współbieżnego zbieracza śmieci, który musi zidentyfikować wszystkie żywe wskaźniki, aby ustalić, które obiekty na stercie pozostają osiągalne. W przeciwieństwie do C, Go traktuje uintptr jako nieprzezroczysty typ całkowity, który nie przenosi metadanych wskaźników, co oznacza, że zbieracz śmieci ignoruje wartości tego typu podczas skanowania korzeni i przeszukiwania wskaźników. Taki projekt pozwala na arytmetykę na adresach, ale tworzy niebezpieczną lukę, w której prawidłowe odniesienia do pamięci mogą pojawić się jako zwykłe liczby, niewidoczne dla śledzenia żywotności przez czas wykonania.
Kiedy programiści wykonują obliczenia adresowe — takie jak dostęp do elementów tablicy bez sprawdzania granic lub wyrównywanie pamięci — często konwertują unsafe.Pointer na uintptr, stosują przesunięcia, a następnie konwertują z powrotem. Jeśli te kroki zachodzą w wielu instrukcjach lub wywołaniach funkcji, pośrednia wartość uintptr staje się jedynym dowodem odniesienia do pamięci. Zbieracz śmieci, nie widząc wskaźnika, może dojść do wniosku, że podstawowy obiekt jest niedostępny i odzyska go, co prowadzi do awarii z użyciem po pamięci po zwolnieniu lub uszkodzenia danych, gdy końcowa konwersja wskaźnika próbuje uzyskać dostęp do teraz nieprawidłowej pamięci.
Go nakazuje, aby każda konwersja z unsafe.Pointer na uintptr i z powrotem musiała odbywać się w tej samej ekspresji, bez pośredniego przechowywania lub wywołań funkcji. Taki wzór zapewnia, że kompilator utrzymuje oryginalny wskaźnik jako żywy przez cały czas operacji arytmetycznej, zapobiegając współbieżnym cyklom zbierania śmieci przed odzyskaniem odwoływanego obiektu. Kanoniczna forma to (*T)(unsafe.Pointer(uintptr(p) + offset)), gdzie całe obliczenie pozostaje pojedynczą oceną.
System przetwarzania pakietów o wysokiej przepustowości musiał parować nagłówki protokołów bezpośrednio z fragmentu bajtów, bez narzutu sprawdzania granic Go. Zespół inżynieryjny potrzebował dostępu do 8. bajtu buforowego MTU o rozmiarze 1500 bajtów, używając arytmetyki wskaźników, aby zaoszczędzić nanosekundy z gorącej ścieżki i spełnić surowe wymagania dotyczące przepustowości 10 Gb/s.
Jednym z podejść było przechowywanie pośredniego obliczenia adresu w zmiennej lokalnej dla przejrzystości: obliczając addr := uintptr(unsafe.Pointer(&buf[0])) + 8, a następnie później dereferencjonując *(*uint64)(unsafe.Pointer(addr)). Chociaż poprawiło to czytelność i umożliwiło debugowanie wartości adresu w punktach przerwania, wprowadzało to krytyczny wyścig — zbieracz śmieci mógł działać między przypisaniem a dereferencją, przenieść bufor do nowej lokalizacji na stercie i sprawić, że addr stanie się zwisającym odniesieniem do starego adresu, powodując naruszenia segmentacji lub uszkodzenie danych.
Alternatywna strategia obejmowała owinięcie arytmetyki w funkcję pomocniczą przyjmującą unsafe.Pointer i przesunięcie, wykonującą rzutowanie wewnątrz tej funkcji. Jednak ponieważ wywołania funkcji działają jako punkty harmonogramowania i mogą wywołać wzrost stosu lub zbieranie śmieci, przekazanie wskaźnika przez argumenty funkcji nie gwarantowało, że kompilator utrzyma żywotność oryginalnego wskaźnika przez cały czas wykonania pomocnika, nadal narażając kod na przedwczesną kolekcję.
Zespół wybrał wzór jednolitych wyrażeń *(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer(&buf[0])) + 8)) otoczony //go:nosplit opaską w stylu assembly. To zapewniło, że arytmetyka wskaźników zachodziła atomowo z perspektywy czasu wykonania, zapobiegając zbieraczowi śmieci dostrzeganiu pośredniego stanu uintptr. To rozwiązanie poświęciło pewną możliwość debugowania na rzecz poprawności, używając rozbudowanych testów jednostkowych i kompilacji z włączonym checkptr podczas CI, aby wykryć nieprawidłowe konwersje.
Procesor pakietów osiągnął ścieżki gorące bez alokacji z stabilną latencją o długości poniżej mikrosekundy. W produkcji nie wystąpiły awarie związane z zbieraczem śmieci, potwierdzone uruchomieniem usługi pod GODEBUG=checkptr=1 podczas testów obciążeniowych, aby zweryfikować, że żadne naruszenia unsafe.Pointer nie umknęły wykryciu.
Dlaczego konwersja unsafe.Pointer do uintptr i przechowywanie go w zmiennej przed konwersją z powrotem narusza gwarancje bezpieczeństwa pamięci Go?
Zbieracz śmieci Go działa współbieżnie i może być uruchomiony w dowolnym punkcie alokacji. Kiedy przechowujesz uintptr w zmiennej, tworzysz okno, w którym obiekt jest referencjonowany tylko przez liczbę całkowitą. Ponieważ wartości uintptr nie są skanowane jako korzenie, GC może odzyskać obiekt w tym oknie, powodując, że kolejna konwersja wskaźnika będzie próbowała uzyskać dostęp do zwolnionej pamięci.
Jak flaga checkptr współdziała z arytmetyką unsafe.Pointer, a dlaczego poprawny kod może powodować nowe paniki pod GODEBUG=checkptr=2?
Instrumentacja checkptr waliduje, że konwersje unsafe.Pointer respektują wyrównanie i granice alokacji. Pod checkptr=2 kompilator wstawia kontrole czasu wykonania, które weryfikują, że arytmetyka pozostaje w granicach oryginalnego obiektu. Prawidłowy kod może spowodować panikę, jeśli arytmetyka wygeneruje wskaźnik do środka obiektu lub pochodzi z wielokrotnego obliczenia uintptr, ponieważ checkptr nie może zweryfikować gwarancji żywotności przez granice instrukcji.
Jaka jest różnica między zasadami unsafe.Pointer a zasadami przekazywania wskaźników cgo w odniesieniu do wskaźników tymczasowych, i kiedy naruszenie tych zasad może spowodować awarię Go podczas wzrostu stosu?
Podczas gdy unsafe.Pointer wymaga atomowych konwersji, cgo nakłada dodatkowe ograniczenia wymagające, aby wskaźniki przekazywane do C pozostały zablokowane. Kandydaci często zakładają, że przechowywanie wskaźników Go jako uintptr w pamięci C jest bezpieczne, ale podczas wzrostu stosu Go lub GC te wskaźniki mogą stać się nieprawidłowe. Rozwiązanie wymaga użycia runtime.Pinner lub zapewnienia, że wywołania C zakończą się przed powrotem do Go, utrzymując invarianty osiągalności przez cały czas wykonania obcej funkcji.