Truy Tìm Và Sửa Lỗi Runtime Go Trên Hệ Thống Nhúng 32-Bit

Một ứng dụng viết bằng Go bất ngờ sập trên hệ thống nhúng Linux 32-bit ARM sau một thời gian dài chạy liên tục. Nguyên nhân không nằm ở code ứng dụng mà ẩn sâu bên trong runtime của Go, liên quan đến cách xử lý con trỏ và sự kiện epoll. Bài viết này giải mã hành trình truy tìm lỗi hiếm gặp này và cách cộng đồng Go đã khắc phục nó.

Triệu Chứng Và Giả Thuyết Ban Đầu

Khách hàng báo cáo rằng ứng dụng Go của họ thỉnh thoảng gặp lỗi nghiêm trọng trên thiết bị nhúng Linux. Lỗi này không xảy ra ngay lập tức mà xuất hiện sau một thời gian dài hoạt động, gây khó khăn cho việc tái hiện và chẩn đoán. Ban đầu, đội ngũ kỹ thuật nghi ngờ code ứng dụng có vấn đề, nhưng khi kiểm tra kỹ hơn, họ nhận thấy lỗi nằm ở cơ chế netpoll bên trong runtime Go.

Thông báo lỗi đến từ hàm netpoll() trong file src/runtime/netpoll_epoll.go. Mã này giả định rằng sự kiện EPOLLIN là sự kiện duy nhất được kích hoạt, nhưng thực tế lại nhận được EPOLLIN|EPOLLOUT (giá trị 5). Điều này vi phạm giả định bên trong runtime, dẫn đến lỗi nghiêm trọng.

Khám Phá Vấn Đề Trên Diễn Đàn Go

Khi tìm kiếm trên mạng, nhóm nghiên cứu nhanh chóng tìm thấy một báo cáo sự cố trong issue tracker của dự án Go có cùng đúng lỗi này. Điểm chung của các báo cáo là tất cả đều xảy ra trên hệ thống Linux nhúng 32-bit ARM hoặc i386, và không có một báo cáo nào trên kiến trúc x86_64 hay arm64. Lỗi vẫn chưa được sửa kể từ tháng 3 năm 2025, và một nỗ lực sửa chữa trước đó đã bị từ chối.

Lỗi này chỉ xuất hiện trên hệ thống 32-bit little endian và cần thời gian dài để bộ đếm fdseq tăng lên đủ lớn, giải thích tại sao nó hiếm khi được phát hiện.

Nguyên Nhân Gốc Rễ: Bí Danh Con Trỏ Trên Kiến Trúc 32-Bit

Đào sâu vào code netpoll, nhóm nghiên cứu phát hiện ra rằng runtime Go lưu trữ hai loại giá trị khác nhau trong trường ev.Data của cấu trúc epoll_event: một con trỏ thô tới đối tượng netpollEventFd hoặc một con trỏ có gắn thẻ (tagged pointer) tới đối tượng pollDesc của socket. Việc trộn lẫn này là điểm mấu chốt.

Trên nền tảng 32-bit, con trỏ chỉ dài 4 byte. Tuy nhiên, Go lại lưu phần địa chỉ vào 4 byte cao và phần tag vào 4 byte thấp của một từ 8 byte. Khi so sánh ev.Data với địa chỉ &netpollEventFd, code lại ép kiểu về uintptr (4 byte trên 32-bit), nghĩa là chỉ so sánh 4 byte thấp. Điều này gây ra bí danh: khi giá trị fdseq (phần tag) trong 4 byte thấp trùng với địa chỉ của netpollEventFd, runtime sẽ nhầm lẫn một socket với event fd.

Sơ đồ minh họa cách lưu trữ con trỏ trong bộ nhớ

Bởi vì netpollEventFd thường nằm trong vùng nhớ chỉ đọc ở 3 MiB đầu tiên của không gian địa chỉ, bộ đếm fdseq cần tăng lên đến khoảng 3 triệu để xảy ra va chạm. Đây là lý do chỉ những ứng dụng chạy lâu và tạo ra nhiều đối tượng pollDesc mới gặp lỗi.

Giải Pháp Và Kết Quả

Nhóm đã đề xuất một giải pháp thay đổi cách phân biệt event fd và socket fd. Thay vì lưu con trỏ thô &netpollEventFd, họ lưu một pollDesc nil dưới dạng con trỏ có gắn thẻ. Nếu kết quả giải mã con trỏ là nil, đó là event fd; nếu không, đó là socket fd. Điều này đảm bảo ev.Data luôn chứa một con trỏ có gắn thẻ, loại bỏ hoàn toàn hiện tượng bí danh.

Phương án sửa lỗi này đã được chấp nhận và hợp nhất vào mã nguồn Go. Lỗi này đã tồn tại từ Go 1.14 (năm 2020) và chỉ được phát hiện sau 5 năm, cho thấy việc thiếu các bài kiểm tra trên nền tảng 32-bit trong quá trình phát triển của Google.

Kết Luận Và Bài Học Kinh Nghiệm

Vụ việc này là một lời nhắc nhở quan trọng về việc hỗ trợ các kiến trúc cũ trong các ngôn ngữ lập trình hiện đại. Lỗi xảy ra do một giả định không chính xác về bố cục bộ nhớ trên các hệ thống 32-bit, và việc thiếu các báo cáo từ người dùng đã khiến vấn đề tồn tại trong thời gian dài. Đây cũng là một minh chứng cho thấy ngay cả các runtime nổi tiếng như Go cũng có thể chứa những lỗi tinh vi chỉ xuất hiện trong điều kiện cụ thể.

Việc sửa lỗi này không chỉ giúp khách hàng của sigma-star mà còn mang lại lợi ích cho cộng đồng Go nói chung, đặc biệt là những người vẫn đang vận hành các hệ thống nhúng 32-bit. Nó nhấn mạnh tầm quan trọng của việc kiểm thử đa nền tảng và sự cần thiết phải duy trì hỗ trợ cho các kiến trúc cũ trong thời đại công nghệ phát triển nhanh chóng.