Bóng ma trong Word 97: Sự cố sập biến mất khi có người nhìn vào

Raymond Chen, kỹ sư kỳ cựu của Microsoft, vừa chia sẻ một câu chuyện đầy ám ảnh về lỗi phần mềm khó chịu nhất trong sự nghiệp: một lỗi sập trong Word 97 mà khi lập trình viên cầm máy lên để kiểm tra thì nó... biến mất.

Nghe như chuyện ma, nhưng đó là cơn ác mộng thực sự của bất kỳ kỹ sư phần mềm nào. Hãy tưởng tượng: bạn có một bản dựng (build) sắp phát hành, một script kiểm thử kích hoạt sự cố khá ổn định trong phòng thí nghiệm, nhưng ngay khi bạn kết nối trình gỡ lỗi (debugger) để truy tìm nguyên nhân, sự cố biến mất không dấu vết. Đây chính là tình huống mà đội ngũ phát triển Word 97 phải đối mặt vào giai đoạn cuối của chu kỳ phát hành.

Khi debugger trở thành "thần chết" của con bug

Raymond Chen kể lại trên blog của mình rằng đội ngũ phát triển rất lo lắng. Một lỗi chỉ xuất hiện lẻ tẻ trong phòng thí nghiệm gần như chắc chắn sẽ xảy ra thường xuyên ở môi trường người dùng thực tế. Nhưng làm sao để gỡ lỗi một vấn đề "kháng" lại việc bị gỡ lỗi?

"Đội ngũ phát triển rất lo lắng, bởi vì một lỗi chỉ xuất hiện lẻ tẻ trong phòng thí nghiệm thì sẽ xảy ra thường xuyên ở ngoài thực tế. Nhưng làm thế nào bạn có thể gỡ lỗi một vấn đề không chịu hợp tác?" — Raymond Chen.

Phải nói rằng, đây là cơn ác mộng của mọi lập trình viên, kể cả những người hay ngả người ra ghế và bảo với tester rằng "thử ở máy tôi thì chạy ngon lành". Vũ trụ có một "chỗ đặc biệt" dành riêng cho những kẻ đó.

ICE huyền thoại và cuộc truy tìm CPU

Với tình thế bế tắc, cuộc tranh luận chuyển sang việc sử dụng một ICE (In-Circuit Emulator) — thiết bị mô phỏng vi xử lý trong mạch, có thể thay thế CPU thật. Điểm mấu chốt của ICE là nó cho phép người lập trình đặt điểm dừng (breakpoint) ngay bên trong chip được mô phỏng, từ đó quan sát được mọi trạng thái bên trong CPU, điều mà debugger phần mềm thông thường không thể làm được.

Theo lời Raymond Chen, với hầu hết lập trình viên phần mềm, thiết bị ICE chỉ tồn tại trong truyền thuyết. Cơ hội được sở hữu và sử dụng nó được ví von với cảm giác phấn khích của một cậu bé 5 tuổi khi được học cách điều khiển một chiếc xe cứu hỏa.

Lỗi CPU errata và giải pháp "nop" thần kỳ

Nhờ có ICE, đội ngũ kỹ sư cuối cùng đã truy ra nguồn gốc sự cố: đó là một lỗi errata (lỗi tài liệu hóa nhưng không public rộng rãi) của một nhà sản xuất CPU cụ thể. Trình biên dịch (compiler) thời đó đã có bản cập nhật để tránh sinh ra đoạn mã máy gây xung đột với CPU lỗi này. Tuy nhiên, vấn đề là lúc đó chu kỳ phát hành Word 97 đã bị "khóa" — không thể đổi sang trình biên dịch mới vì rủi ro gây ra những lỗi mới không lường trước.

Giải pháp được chọn là một bản vá nhị phân (binary patch): các kỹ sư phải dò tìm trong file thực thi (binary) của Word, tìm đúng đoạn mã máy có khả năng gây ra lỗi errata trên CPU. Họ chỉ tìm thấy một chỗ duy nhất. Và để tránh gây ra bất kỳ ảnh hưởng phụ nào, kỹ thuật cổ điển được sử dụng: chèn một lệnh NOP (No Operation) vào ngay giữa đoạn mã có vấn đề. Một lệnh NOP chỉ đơn giản là "không làm gì cả" — nhưng nó lại làm thay đổi cách CPU nạp và thực thi các lệnh tiếp theo, từ đó né được lỗi phần cứng.

Bài học cho kỹ sư hiện đại

Word 97 giới thiệu nhiều tính năng đình đám như Clippit (hay còn gọi là Clippy) hay VBA. Nhưng bản vá nhị phân này, một sản phẩm của sự kiên trì và kinh nghiệm, lại không nhận được sự chú ý nào. Tuy nhiên, nếu không có nó, Word 97 có thể đã "lung lay dữ dội" trên một số dòng CPU nhất định.

Câu chuyện này nhắc nhở chúng ta rằng phần cứng không hoàn hảo, và phần mềm cũng vậy. Trong một thế giới mà các hệ thống ngày càng phức tạp, việc phải "vá" một lỗi do CPU gây ra bằng một lệnh nop là minh chứng cho thấy đôi khi, giải pháp hack não nhất lại là giải pháp an toàn và hiệu quả nhất. Nó cũng cho thấy nghệ thuật của một kỹ sư phần mềm không chỉ dừng lại ở việc viết code mà còn là khả năng đối mặt với những "bóng ma" không thể giải thích trong máy móc.