Crash reporter mới của Bun

Crash Reporter mới của Bun

• Trong Bun v1.1.5, một định dạng báo cáo crash mới đã được tạo cho Zig và C++
• Báo cáo crash được chứa trong một URL khoảng 150 byte hoàn toàn không có thông tin cá nhân

Vì sao không dùng crash reporter của OS?

• Một số OS như macOS có crash reporter tích hợp sẵn, nhưng thường phải phân phối debug symbol cùng với ứng dụng
• Debug symbol cho Linux có dung lượng khoảng 30MB, macOS khoảng 9MB
• Trên Windows, file .pdb có thể lớn hơn 250MB
• Quá nặng để thêm vào mọi bộ cài đặt của Bun
• Nhưng nếu không có debug symbol thì thông tin crash sẽ rất hạn chế, và do ASLR nên mọi địa chỉ hàm đều trở nên vô dụng

Crash reporter mới

• Trong Bun v1.1.5, khi xảy ra crash hoặc panic, một thông báo sẽ được in ra
• Khi nhấp vào liên kết bun.report, người dùng sẽ được chuyển hướng tới một biểu mẫu issue GitHub được điền sẵn, trong đó stack trace đã được mã hóa vào URL

Làm cho địa chỉ trở nên hữu ích

• Địa chỉ hàm là con trỏ tới vùng nhớ nơi mã ứng dụng được nạp, kèm theo offset được ngẫu nhiên hóa vì lý do bảo mật
• Mẹo ở đây là chỉ cần trừ địa chỉ khỏi base address của binary
• Mỗi nền tảng có API khác nhau nên trên thực tế hàm này phức tạp hơn nhiều
• Địa chỉ kết quả vẫn còn bao gồm offset đối với image
• Để mã hóa URL ngắn hơn, offset này sẽ bị loại bỏ nhưng phải được thêm lại trước khi remap

Cấu trúc URL của bun.report

• Nếu phân tích cách URL được mã hóa:
  • Nền tảng: Một ký tự duy nhất biểu thị nền tảng. w là x86_64 Windows, M là aarch64 macOS, v.v.
  • Lệnh con: Một ký tự duy nhất biểu thị subcommand như bun test, bun install, bun run, v.v.
  • Commit SHA: Commit SHA của phiên bản Bun hiện tại. Về sau được dùng để lấy debug symbol
  • Feature Flags: Dấu hiệu về các API và tính năng đã được dùng trước khi Bun bị crash
  • Địa chỉ stack trace: Các địa chỉ đã được tính toán ở trên
  • Loại crash: Một ký tự duy nhất biểu thị loại crash
  • Thông điệp crash: Thông điệp của crash, có định dạng khác nhau tùy theo loại

VLQ rất thú vị

• Để giữ URL đủ ngắn, các địa chỉ stack trace được mã hóa bằng số lượng có độ dài biến thiên base64
• Các số nhỏ có thể được mã hóa bằng ít ký tự hơn nhưng vẫn cho phép mã hóa số lớn
• Đây cũng là kỹ thuật được dùng để lưu số dòng trong source map của JavaScript

“Feature” là gì?

• URL cũng mã hóa một số nguyên 64 bit, trong đó mỗi bit tương ứng với việc có sử dụng một tính năng cụ thể nào đó của Bun hay không
• Các flag này cung cấp gợi ý về API và hệ thống có thể đã dẫn tới crash
• Metaprogramming tại thời điểm biên dịch của Zig giúp việc tạo bitfield này trở nên dễ dàng
• Đã có sẵn một container của các biến toàn cục để theo dõi tính năng
• Có thể dùng std.meta để lặp qua danh sách tính năng và tạo danh sách
• Sau đó tạo một packed struct được suy ra động để dùng một bit cho mỗi tính năng

So với core dump thì sao?

• Core dump chứa nhiều thông tin hơn rất nhiều, nhưng có kích thước lớn, cần có debug symbol mới hữu ích, và có thể bao gồm nhiều thông tin nhạy cảm hoặc bí mật
• Họ muốn tránh khả năng gửi mã nguồn JavaScript/TypeScript, biến môi trường hoặc các thông tin quan trọng khác trong báo cáo
• Đây là lý do chỉ gửi stack trace Zig/C++ và một vài chi tiết khác
• Thay vì mặc định gửi mọi thứ, cách tiếp cận này (có lẽ) chỉ gửi những gì cần thiết để chẩn đoán vấn đề

Demo

• Có một web app nhỏ trên trang chủ bun.report để bạn có thể thử crash reporter
• Nếu thêm /view vào cuối URL báo cáo crash, bạn sẽ đến đây

Bun đang tuyển dụng tại San Francisco

• Nếu bạn quan tâm tới các dự án như thế này, họ đang tuyển kỹ sư tại San Francisco
• Họ đang tìm các kỹ sư hệ thống để góp phần xây dựng tương lai của JavaScript

Ý kiến của GN+

• Thay vì gửi toàn bộ file crash dump có thể chứa thông tin nhạy cảm như dữ liệu cá nhân, cách gửi báo cáo crash chỉ với lượng thông tin tối thiểu cần thiết có vẻ là một hướng tiếp cận tốt.

• So với core dump, ưu điểm là có thể cung cấp thông tin cần thiết với dung lượng nhỏ hơn nhiều, nhưng cũng có nhược điểm là có thể thiếu thông tin cần cho việc debug. Điểm hạn chế này có lẽ phần nào được bù đắp vì có thể yêu cầu thêm thông tin từ người dùng khi cần.

• Ý tưởng mã hóa địa chỉ stack trace bằng VLQ khá ấn tượng. Đây là một cách hiệu quả để truyền được nhiều thông tin trong kích thước nhỏ. Việc đây cũng là kỹ thuật được dùng trong source map của JavaScript là một ví dụ ứng dụng thú vị.

• Nhìn chung, có vẻ đã có rất nhiều suy nghĩ và ý tưởng sáng tạo được đưa vào thiết kế của hệ thống báo cáo crash này. Nó có thể đóng góp đáng kể vào việc cải thiện độ ổn định và khả năng sử dụng của Bun thông qua các báo cáo crash thực tế.

• Nếu cần thêm thông tin không có trong báo cáo mặc định, có vẻ người dùng sẽ phải tự tìm hiểu và cung cấp thông tin về từng trường trong báo cáo crash, điều này có thể khó hiểu nếu không phải người dùng nâng cao. Cũng đáng cân nhắc các cách cải thiện trải nghiệm thân thiện hơn với người dùng.