Przed Go 1.6, programiści mogli swobodnie przekazywać wskaźniki między Go a C, co prowadziło do sporadycznych awarii, gdy garbage collector przenosił obiekty sterty, podczas gdy kod C utrzymywał odniesienia. Aby zapobiec tym naruszeniom bezpieczeństwa pamięci, Go 1.6 wprowadziło rygorystyczne zasady przekazywania wskaźników, zabraniające C przechowywania Go wskaźników po zakończeniu wywołania. Czas wykonywania implementuje system weryfikacji nazwany cgocheck, aby egzekwować te ograniczenia podczas wykonywania programu.
Kod C działa poza zarządzaniem pamięcią czasu wykonywania Go, co oznacza, że przydzielona pamięć C jest niewidoczna dla precyzyjnego garbage collectora. Jeśli C przechowuje wskaźnik do obiektu Go w zmiennej globalnej lub przydzieleniu na stosie, a ten obiekt jest później przeniesiony przez GC (w przyszłych implementacjach GC) lub staje się niedostępny z Go, dereferencjonowanie tego wskaźnika powoduje błędy użycia po zwolnieniu lub uszkodzenie danych. Wykrycie tego wymaga skanowania pamięci C podczas zbierania śmieci, co jest kosztowne obliczeniowo i niepraktyczne w środowiskach produkcyjnych domyślnie.
Czas wykonywania zapewnia zmienną środowiskową GODEBUG=cgocheck z trzema trybami. Tryb 1 (domyślny) sprawdza, czy argumenty przekazywane do funkcji C nie zawierają Go wskaźników do innych Go wskaźników. Tryb 2 umożliwia kosztowne konserwatywne skanowanie pamięci stosu i sterty C podczas GC w celu wykrycia wszelkich Go wskaźników utrzymywanych w przestrzeni C, panikując, jeśli są obecne. Tryb 0 wyłącza wszystkie kontrole. Tryb 2 jest wyłączony domyślnie, ponieważ narzuca znaczne obciążenie wydajności (do 50% spowolnienia) traktując pamięć C jako potencjalne korzenie wskaźników podczas każdego cyklu GC.
Podczas budowy adaptera dla kolejki wiadomości o wysokiej przepustowości opakowującego bibliotekę C (librdkafka), musieliśmy przekazywać ładunki wiadomości jako fragmenty bajtów z Go do C w celu asynchronicznej transmisji wsadowej. Biblioteka C kolejkowała te wskaźniki w wewnętrznej liście połączonej na późniejszą transmisję sieciową za pomocą wątków w tle, łamiąc zasadę CGO, że C nie może przechowywać wskaźników Go po zwróceniu kontroli. Podczas testowania obciążenia powodowało to sporadyczne błędy segmentacji, gdy Go GC odzyskiwał dane tablicy, podczas gdy C nadal trzymało odniesienia.
Rozwiązanie 1 - Kopiuj do sterty C: Rozważaliśmy kopiowanie każdego ładunku wiadomości do pamięci przydzielonej przez C za pomocą C.malloc, a następnie zwalnianie go w wywołaniu zwrotnym dostawy. Zalety: Całkowicie bezpieczne, brak zatrzymywania wskaźników Go, działa z każdą wersją Go. Wady: Podwójne przydzielanie pamięci (Go do C), narzuty CPU dla memcpy dla dużych wiadomości (1MB+), a ryzyko wycieków pamięci, jeśli wywołanie zwrotne C nie zwolni bufora podczas timeoutów sieciowych.
Rozwiązanie 2 - Użyj cgo.Handle: Ocena polegała na przechowywaniu fragmentu bajtów Go w cgo.Handle (token całkowity) i przekazaniu tylko liczby całkowitej do C, co wymaga wywołania zwrotnego do odzyskania danych. Zalety: Zero-kopiowy dla ładunku, zarządzanie referencją bezpieczne w typach oraz idiomatyczny wzór Go 1.17+ dla długoterminowego przechowywania w C. Wady: Wymaga implementacji mechanizmu wywołania zwrotnego w kodzie C, zwiększa opóźnienie z powodu dodatkowego przekroczenia granicy CGO w celu pozyskania danych, a tabela uchwytów rośnie bez ograniczeń, jeśli C nigdy nie sygnalizuje zakończenia.
Rozwiązanie 3 - Pinowanie czasu wykonywania (Go 1.21+): Zapewnialiśmy użycie runtime.Pinner, aby zapobiec przenoszeniu lub zbieraniu przez GC fragmentu bajtów, podczas gdy C trzymało odniesienie. Zalety: Prawdziwy zero-kopiowy bez przydzielania pamięci w C, bezpośrednie współdzielenie pamięci i minimalne narzuty API. Wady: Wymaga Go 1.21+, ręczne zarządzanie cyklem życia (ryzyko wycieków pamięci, jeśli Unpin nie zostanie wywołane we wszystkich ścieżkach błędów) oraz trudności w debugowaniu zablokowanej pamięci, ponieważ pojawia się jako utrzymujące się obiekty sterty w profilach.
Wybraliśmy cgo.Handle (Rozwiązanie 2), ponieważ architektura adaptera już wymagała potwierdzenia dostawy. To podejście wyeliminowało kopiowanie danych dla naszego wymogu przepustowości 100MB/s przy zachowaniu bezpieczeństwa w różnych wersjach Go. Dodaliśmy jawne usunięcie uchwytu w obu potwierdzeniach sukcesu i błędu, aby zapobiec wyciekom.
System osiągnął stabilne latencje 99,9. percenty poniżej 10ms i przetworzył ponad 500k wiadomości na sekundę w produkcji. Przeszedł testy obciążeniowe trwające tydzień z włączonym GODEBUG=cgocheck=2, aby zweryfikować brak naruszeń wskaźnika. Profile pamięci potwierdziły brak wycieków z gromadzenia uchwytów dzięki właściwemu czyszczeniu w wszystkich ścieżkach kodu.
Dlaczego domyślny tryb cgocheck=1 nie wykrywa Go wskaźników przechowywanych w globalnych zmiennych C po zwróceniu kontroli?
Domyślny tryb tylko weryfikuje natychmiastowe argumenty i wartości zwracane przekraczające granicę CGO w celu wykrycia naruszeń wskaźników-do-wskaźników; nie skanuje pamięci C (zmiennych globalnych, sterty lub stosu) w celu wykrycia utrzymywanych wskaźników Go. Tylko GODEBUG=cgocheck=2 umożliwia konserwatywne skanowanie pamięci C podczas zbierania śmieci w celu wykrycia takich zatrzymań. Ta kosztowna kontrola jest wyłączona domyślnie, ponieważ wymaga traktowania całej pamięci C jako potencjalnych korzeni GC, co znacznie zwiększa czasy pauzy i zużycie CPU podczas cykli zbierania.
Jak cgo.Handle zapobiega odzyskiwaniu przez garbage collector odniesionego Go wartości, podczas gdy kod C trzyma token całkowity?
cgo.Handle przechowuje wartość Go w wewnętrznej mapie czasu wykonywania (w pakiecie runtime/cgo) wykorzystując liczbę całkowitą jako klucz. Ponieważ mapa utrzymuje odniesienie do wartości, garbage collector oznacza ją jako osiągalną podczas skanowania korzeni i nie odzyska pamięci. Liczba całkowita przekazywana do C nie zawiera metadanych wskaźników, więc C może przechowywać ją w nieskończoność, nie zakłócając zarządzania pamięcią Go. Gdy C wywołuje wywołanie zwrotne lub Go jawnie usuwa uchwyt, wpis mapy jest usuwany, co zmienia odniesienie i pozwala na normalne zbieranie.
Jaka konkretna panika wskazuje naruszenie przekazywania wskaźników CGO podczas wywołania funkcji, a jaki flag czasu wykonywania modyfikuje jej czułość wykrywania?
Czas wykonywania generuje błąd wykonania: argument cgo ma wskaźnik Go do wskaźnika Go gdy cgocheck=1 wykryje wskaźnik do pamięci Go wewnątrz argumentu przekazywanego do C. Aby rozszerzyć wykrywanie włączając wskaźniki przechowywane w pamięci C, must be enabled GODEBUG=cgocheck=2, co może spowodować runtime: wynik cgo zawiera wskaźnik Go lub podobne błędy krytyczne podczas skanowania GC. Te paniki wskazują, że kod C naruszył umowę, przechowując lub otrzymując wskaźniki do pamięci zarządzanej przez Go, która może stać się nieważna podczas zbierania śmieci.