Chiến lược tìm Heisenbugs

Question

Hiện tại tôi lại một lần nữa trong tình huống mà tôi phải tìm nguyên nhân gây ra lỗi mà hầu như không bao giờ xảy ra khi trình gỡ rối đang chạy (có thể là một số điều kiện chủng tộc). Những điều duy nhất tôi có thể nghĩ ra để tìm thấy nó là:

1. Thêm sửa lỗi và xác nhận mã cho tôi biết điều gì đang diễn ra mà không có trình gỡ lỗi.
2. Bước qua mã và suy nghĩ qua mọi dòng và các tác dụng phụ có thể có.

Tất cả điều này rất bực bội. Chiến lược và kinh nghiệm của bạn với những loại lỗi này là gì?

Chỉnh sửa: Tôi đang sử dụng Visual C++ 2005, nhưng tôi nghĩ câu hỏi này áp dụng nhiều (tất cả) ngôn ngữ và môi trường phát triển.

Answer 1

Khi tất cả các kỹ thuật kết thúc và BoundsCheckers hoặc RationalPurify không được trợ giúp. Tôi thường sử dụng kỹ thuật rất câm. Chúng tôi đã phát hiện ra nó ở năm đầu tiên của trường đại học. Trong tiếng Nga nó được gọi là rất thô.

Vì vậy - tôi bắt đầu chọn khối/mô-đun đáng ngờ không hoạt động trong môi trường đa luồng. Nếu điều đó là không thể, thì cấu trúc chương trình sẽ được tính lại.

Khi mô-đun được chọn, tôi sẽ nhận xét các khối mã nhỏ cho đến khi ngoại lệ biến mất. Điều này cho phép xác định chính xác nguyên nhân gây ra (ví dụ điều kiện chủng tộc). Nếu ở bước này bạn có thể nói cái gì sai - thế thì nó là tuyệt vời.

Nếu không, cùng một kỹ thuật được áp dụng để phát hiện trước điều kiện của lỗi, vì vậy tôi là mã nhận xét để mở rộng khối thủ phạm.

Answer 2

Tôi đã tìm thấy rằng chạy lint trên mã C/C++/Java của tôi và đảm bảo rằng tôi khắc phục mọi cảnh báo mà nó cung cấp đã dẫn đến những điều kiện chủng tộc này chỉ biến mất. Nhưng đó không phải là giải pháp. Không bao giờ được mã bởi trùng hợp ngẫu nhiên. Bạn phải hiểu những gì bạn đã khắc phục và lý do tại sao nó khắc phục được sự cố.

Tôi tin rằng đó là K (& & ||) R cho biết rằng các thông điệp ghi nhật ký phong phú đã làm nhiều hơn để giúp họ gỡ lỗi mã hơn bất kỳ trình gỡ lỗi nào - đặc biệt trong môi trường nhiều luồng.

Cẩn thận xem xét một dấu vết rất chi tiết của tất cả các hoạt động dẫn đến lỗi phát sinh thực sự giúp ích rất nhiều.

Answer 3

Nếu bạn có thể xác định các điểm (s) mà tại đó các vấn đề là lần đầu tiên nhìn thấy (không phải khi nó được gây ra, rõ ràng), nâng cao một ngoại lệ đó và sử dụng Process Dumper để có được một bãi chứa để gỡ lỗi sau khi chết.

Chạy tệp nhị phân Phát hành ngoài IDE và đính kèm trình gỡ lỗi sau đó. Điều này tránh heap đặc biệt và các cờ khác chạy bên trong trình gỡ lỗi cho phép.

Nếu bạn có BẤT K idea ý tưởng nào về lỗi, hãy trích xuất mã đó vào một ứng dụng thử nghiệm tối thiểu đủ để búa trên đó càng nhiều càng tốt - bạn đang cố gắng thử nghiệm nó để hủy. Một lần nữa, đính kèm trình gỡ lỗi chỉ sau khi mã được chạy và chạy để tránh nhiều tác dụng phụ cụ thể của Trình gỡ lỗi.

Tùy chọn kiểm tra - Xây dựng với /W4 chỉ để đảm bảo không có gì hiển nhiên bị bỏ qua.Kiểm tra mã và cảnh báo đối với phôi kiểu C hoặc reinterpret_cast trong trường hợp ai đó đã bỏ qua miunderstood nhưng cảnh báo quan trọng hoặc thông báo lỗi.