Simulation stop without reason sends a fake `Ok` and desynchronises testcases and results
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 65/100
Hướng nghiên cứu
Read src/haps/mod.rs around on_simulation_stopped_without_reason and src/fuzzer/mod.rs around the referenced exit handling. Trace how an iteration’s exit kind and timeout are managed, then verify the suggested behavior against the surrounding callbacks. Done means a stop without a reason leaves the iteration pending without shifting later testcase results; the issue says this has not yet been reproduced under SIMICS.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Where
- https://github.com/intel/tsffs/blob/79972db9c63eba3ac8a1ce348264eee2005b2b16/src/haps/mod.rs#L493-L531
- https://github.com/intel/tsffs/blob/79972db9c63eba3ac8a1ce348264eee2005b2b16/src/fuzzer/mod.rs#L533-L537
Problem
on_simulation_stopped_without_reason sends ExitKind::Ok for the iteration still in flight and cancels its timeout.
Impact
User pauses mid-iteration (Ctrl-C, unrelated breakpoint) and continues: the fuzzer has consumed Ok for T1 and moved to T2; when T1 really finishes, its result is attributed to T2 and every later result is off by one (non-crashing inputs saved as solutions). The rest of T1 runs with no timeout. With shutdown_on_stop_without_reason = True the thread exits later and the next channel send/recv panics in a HAP callback.
Suggested fix
When not shutting down, send no exit kind and keep the timeout armed; leave the iteration pending.
Status
Reported by static code review at 79972db; not yet re-verified line by line. Found by reading the code; not reproduced under SIMICS.
- Ngôn ngữ chính
- Rust
- Star
- 335
- Fork
- 26
- Merge trung bình
- 1 ngày 50 phút
- Pull request đã merge (30 ngày)
- 12
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của intel/tsffs
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
bug UI
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
wardian-app/Wardian#1746 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
jlcodes99/cockpit-tools#3125 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug user-sprint
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Vondor/KassenSturz#967 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area/ci
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] Incremental sync warns "no stored highest_uid" on every round for folders with no new mailĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
rustmailer/bichon#411 ·