elfuse segfaults after a failed guest init under a host RLIMIT_AS
Maintainer thường phản hồi trong vòng 3 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
- 55/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ệ
- c, macos
- Lĩnh vực
- backend, operating-systems
Hướng nghiên cứu
Read the guest initialization failure path at src/core/bootstrap.c:421 and the mmap error handling at src/core/guest.c:608. Reproduce with the 1 TiB host limit using the command described in the issue and ELFUSE_STARTUP_TRACE=1; the evidence shows the crash occurs after guest_init fails. Done means elfuse reports the setup failure and exits non-zero without a segmentation fault.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Background
Guest rlimits are seeded from elfuse's host limits at boot, so #448 added tests/test-rlimit-seed.sh, which starts elfuse under ulimit -v and reads the guest's /proc/self/limits. With the limit at 1.5 TiB the lane passed on macOS 27 but exited 139 on the CI runner, in its first case and with nothing on stderr, on both runs of ae9252b. #448 now uses 6 TiB, where the runner passes. Draft PR #457 then ran elfuse on the runner at three limits and found two separate crashes. This issue is the one at 1 TiB; the one at 1.5 TiB is #459.
Intention
When elfuse cannot set up guest memory, it should report that and exit non-zero, as it already starts to do here, instead of segfaulting on the way out.
Evidence
#457 job on the runner: macOS 26.4.1 (25E253), Mac16,10 (M4), 24 GiB, elfuse at #448's tip. Every run was started as bash -c 'ulimit -v <KiB>; exec elfuse ...' with ELFUSE_STARTUP_TRACE=1.
ulimit -v |
elfuse --version |
busybox true, --verbose busybox cat /proc/self/limits, test-proc-limits |
Last startup step reached |
|---|---|---|---|
| 1 TiB | exit 0 | exit 139, every run | none after primary_mmap |
| 1.5 TiB | exit 0 | exit 139, every run (#459) | build_linux_stack |
| 6 TiB | exit 0 | exit 0 | hv_vcpu_create, then the guest runs |
--version boots no guest and never crashed, and the guest never ran an instruction in any crashing run, so the segfault is in the elfuse host process.
At 1 TiB all three slab sizes fail, 2^40, 2^38 and 2^36 bytes, and elfuse reports it, then dies:
startup primary_mmap 1.296 ms
guest: mmap: Cannot allocate memory
startup primary_mmap 0.275 ms
guest: mmap: Cannot allocate memory
startup primary_mmap 0.070 ms
guest: mmap: Cannot allocate memory
ERROR src/core/guest.c:608: guest: hv_vm_map failed at every attempted slab size (start=40-bit, floor=36-bit)
ERROR src/core/bootstrap.c:422: failed to initialize guest
Segmentation fault: 11
So the crash is on the path that runs after guest_init returns an error (src/core/bootstrap.c:421), which should have ended in a clean exit.
Not confirmed:
- Which instruction faults. The runner left no crash report under
~/Library/Logs/DiagnosticReportsfor these processes. - Whether the failure path crashes only under an AS limit. Any
guest_initfailure takes the same path, but no other way to make it fail was tried. - Why the runner needs so much more address space. On macOS 27 (M-series) the same build boots under 1 TiB by falling back to a smaller slab; on the runner even the 2^36 slab fails under 1 TiB.
Refs #448, #457
- Ngôn ngữ chính
- C
- Star
- 275
- Fork
- 29
- Merge trung bình
- 2 ngày 8 giờ
- Pull request đã merge (30 ngày)
- 17
Chuẩn bị môi trường
- Không có Dockerfile hay 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 sysprog21/elfuse
-
Độ khó 2/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 3 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 3 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Maintainer thường phản hồi trong vòng 3 ngày
Tất cả issue của sysprog21/elfuse
Issue tương tự
-
[Bug] Unhandled ValueError terminates watchdog thread when GISRC value contains multiple colonsĐang mởbug
Độ 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
-
bug Component component: net
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
RT-Thread/rt-thread#11913 · 1 bình luận ·
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 72/100
contiki-ng/contiki-ng#3289 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
area:docs help wanted type:enhancement
Độ 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 83/100
semantic-reasoning/wirelog#2229 ·
Maintainer thường phản hồi trong vòng 1 ngày