Windows: CR3-write refresh never fires
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Read src/os/windows/mod.rs around lines 256–283 and src/lib.rs around line 628 to trace the CR3 cache check, insertion, and callback error handling. The issue reports the condition can never pass and notes that collection reparses PDBs; first verify those paths and inspect nearby tests or SIMICS guidance. Done means refreshes occur when a processor's CR3 changes and collection errors do not abort the callback.
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/os/windows/mod.rs#L256-L283
- https://github.com/intel/tsffs/blob/79972db9c63eba3ac8a1ce348264eee2005b2b16/src/lib.rs#L628
Problem
The guard requires cr3_cache.get(..).is_some_and(|v| *v != value), but cr3_cache is only inserted inside that block; no other writer exists.
Impact
The symbol tree stays frozen at the process current at fuzz start; code in other processes or later-loaded modules gets no symbolic coverage.
Suggested fix
Use self.cr3_cache.get(&processor_nr) != Some(&value), insert first, and log-and-continue on collect() errors (the callback is .expect()ed in lib.rs, so an error would abort SIMICS). collect() is also expensive (re-parses PDBs).
Status
Confirmed by reading the code at 79972db. 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 ·