Iteration limit drops the result of the final iteration
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
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust
- Lĩnh vực
- security, testing-qa
Hướng nghiên cứu
Read src/haps/mod.rs lines 113–145 and trace the iteration-limit branch alongside the fuzzer_tx.send(exit_kind) call and solution/timeout counter updates. Check how the fuzzer thread is started and stopped to understand the quit race. Done when the final iteration’s exit kind and counters are recorded before quitting, and the fuzzer thread can finish its disk writes; the issue notes this has not 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
Problem
The iteration-limit check returns/quits before fuzzer_tx.send(exit_kind) and before the solution/timeout counters are updated.
Impact
With iteration_limit = N, a crash on execution N is never saved and counters are short by one. quit(0) also races the fuzzer thread's disk writes.
Suggested fix
Update counters and send the exit kind before the limit check; make the fuzzer thread joinable before quitting.
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 ·