Kinh Nghiệm Xây Dựng Trình Gỡ Lỗi Lua

Anonymous trong Thuật Toán và Internet Vạn Vật

2009-05-01 Khoảng 1200 từ 6 phút

Nội dung

Cách đây vài năm, tôi đã từng thử xây dựng một trình gỡ lỗi cho ngôn ngữ Lua và có đăng hình ảnh chụp màn hình lên blog cá nhân. Tuy nhiên, tôi nhanh chóng nhận ra rằng thiết kế giao diện không phải là yếu tố cốt lõi - mà chính giao thức truyền thông giữa các thành phần mới là phần quan trọng nhất. Phiên bản trước đây mà tôi hoàn thành còn tồn tại nhiều thiếu sót trong thiết kế.

Gần đây, đồng nghiệp trong nhóm kỹ sư yêu cầu mạnh mẽ cần tích hợp một công cụ gỡ lỗi chuyên nghiệp vào engine. Dù bản thân tôi không quá phụ thuộc vào việc debug khi viết code, thậm chí còn cho rằng những đoạn code chỉ chạy đúng sau nhiều lần sửa lỗi liên tiếp không thể coi là code chất lượng cao. Nhưng cuối cùng, vào cuối tuần vừa rồi tôi vẫn quyết định tái thiết kế một trình gỡ lỗi hoàn toàn mới.

Trong quá trình triển khai, tôi gặp phải không ít trở ngại nghiêm trọng, ghi lại tại đây để làm tư liệu

Bài toán tối ưu hóa hiệu năng

Điểm khiến tôi bận tâm nhất lúc bắt đầu là hiệu năng bị ảnh hưởng bởi cơ chế debug hook của Lua. Vì vậy tôi đã dành nhiều thời gian nghiên cứu các giải pháp tối ưu hóa. Dù biết rằng “tối ưu hóa sớm là nguồn cội của mọi rắc rối” như lời Martin Fowler từng cảnh báo, nhưng việc xây dựng một trình gỡ lỗi gần như không làm giảm hiệu năng hoạt động vẫn là một mục tiêu hấp dẫn. Đây cũng không thể xem là tối ưu hóa sớm vì ý tưởng này đã được tôi ấp ủ suốt nhiều năm trời, cùng với việc suy nghĩ kỹ lưỡng về các chiến lược tối ưu.

Tôi đã đề xuất một cơ chế trạng thái debug ba cấp độ:

Chế độ không hook: Khi chưa thiết lập breakpoint, cho phép chương trình Lua chạy tối đa hiệu năng. Chỉ cần định kỳ kiểm tra xem có tín hiệu điều khiển từ client hay không (tương tự như mô hình remote debug của gdb). Việc polling này có thể tích hợp vào vòng lặp chính của ứng dụng, gần như không ảnh hưởng đến tiến trình chính.
Chế độ hook mật độ cao: Sử dụng cơ chế line hook của Lua để theo dõi từng dòng lệnh, phục vụ việc phát hiện và xử lý breakpoint.
Chế độ hook mật độ thấp: Chỉ kích hoạt hook ở sự kiện call/return, giúp nắm bắt bước đi của chương trình qua các hàm được gọi.

Vấn đề với call/return hook

Ban đầu tôi dự định dùng call/return hook để theo dõi vị trí source file/hàm đang thực thi. Khi phát hiện không có breakpoint, hệ thống sẽ tự động chuyển sang chế độ 3. Tuy nhiên trong thực tế, việc đơn giản lấy thông tin source từ call/return hook là chưa đủ.

Vấn đề nằm ở việc:

Khi xảy ra sự kiện call hook, chương trình đã bước vào hàm được gọi
Khi return hook được kích hoạt, con trỏ vẫn đang nằm tại dòng cuối cùng của hàm gọi

Điều này khiến hệ thống có thể bỏ lỡ việc quay lại hàm gọi. Ví dụ với đoạn code trong a.lua:

1
2


foo1()
foo2()

Nếu cả hai hàm này đều được định nghĩa trong b.lua, và chỉ hook call/return, bạn sẽ thấy rằng trong suốt quá trình thực thi foo1() và foo2(), hệ thống không quay lại a.lua. Điều này khiến breakpoint đặt trên foo2() không hoạt động như mong đợi.

Giải pháp tôi áp dụng là khi gặp sự kiện return hoặc tail return, hệ thống sẽ kiểm tra thêm một tầng stack nữa để xác định chính xác source của hàm gọi. Tuy nhiên giải pháp này vẫn tồn tại giới hạn khi gặp trường hợp hàm được gọi từ C hoặc code sinh ra tại runtime.

Lưu ý về tail return và breakpoint

Lua phân biệt rõ ràng giữa return thông thường và tail return. Đây là yếu tố quan trọng cần xử lý khi triển khai chức năng step over. Về vấn đề xác định dòng code hợp lệ khi đặt breakpoint, tôi phát hiện ra rằng mặc dù debug module của Lua có hỗ trợ một phần, nhưng độ tin cậy chưa cao. Việc theo dõi vị trí thực thi hiện tại để tìm vị trí breakpoint phù hợp khiến logic code trở nên phức tạp.

Quản lý metatable khi debug

Khi xem giá trị biến trong trình debug, cần đặc biệt lưu ý đến các hiệu ứng phụ từ metatable. Tốt hơn hết nên dùng rawget để truy xuất giá trị trong table, đồng thời cẩn trọng với các hàm metamethod tostring.

Hỗ trợ code tự sinh code

Trong các trường hợp sử dụng nâng cao, Lua thường được dùng để sinh ra code mới. Việc tích hợp cơ chế nhận diện và hỗ trợ các đoạn code này (bao gồm định dạng source code, tương thích cả ký tự newline của Unix và DOS) mang lại nhiều tiện ích đáng kể.

Quá trình triển khai

Ngày thứ Bảy tôi đã hoàn thành bản đầu tiên, nhưng sau đó phát hiện một số lỗi tiềm ẩn. Càng xem lại code, tôi càng thấy nhiều điểm chưa ổn, nên Chủ Nhật đã quyết định viết lại hoàn toàn từ đầu.

Phiên bản mới xây dựng dựa trên mô hình state machine rõ ràng, phân chia rạch ròi giữa các trạng thái:

Chế độ chạy (running)
Chế độ tương tác (blocking interaction)
Các trạng thái con trong từng trạng thái lớn

Việc chuẩn bị giao diện frontend đồ họa phía sau đòi hỏi phải có một giao thức điều khiển chặt chẽ. Tôi đã nghiên cứu kỹ tài liệu và tham khảo mô hình giao thức của gdb.

Tổng kết

Hoàn thành xong cảm giác vô cùng kiệt sức. Không ngờ sau đó còn phát sinh vô số yêu cầu nhỏ lẻ khác. May mà tôi đã quyết định viết lại từ đầu, nếu không chắc chắn không thể hoàn thành trong cuối tuần. Nếu không tính phần socket communication (đã có module riêng từ trước), hiện tại code Lua tạm dừng ở mức khoảng 1000 dòng - gọn hơn bản đầu tiên nhưng vẫn dài hơn kỳ vọng ban đầu.

Thú vị ngoài lề

Khi chọn port mặc định cho debug server, tôi chọn 3563 - tương đương 0xdeb trong hệ thập lục phân. Không ngờ Sean hôm qua cho biết đây là port nổi tiếng trong hệ thống Wacom C. Thật trùng hợp thú vị!