Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

elfuse segfaults after a failed guest init under a host RLIMIT_AS

オープン
  • 何か問題がありますか？
#458 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, macos
領域
backend, operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

bug

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

Where each run stops in elfuse's boot:

                                               #459 at 1.5 TiB: segfault in here
                                               │             6 TiB: reaches here
                                               ▼             ▼
┌─────────┬────────────┬─────────┬─────────────┬─────────┬───────┐
│ primary │ guest_init │ ...boot │ build_linux │ hv_vcpu │ guest │
│  mmap   │   (slab)   │  steps  │   _stack    │ _create │ runs  │
└─────────┴────────────┴─────────┴─────────────┴─────────┴───────┘
                ▲
                #458 at 1 TiB: slab fails, error printed, segfault on the way out

--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/DiagnosticReports for these processes.
  • Whether the failure path crashes only under an AS limit. Any guest_init failure 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

主要言語
C
スター
275
フォーク
29
平均マージ
2日 8時間
マージ済み PR（30日）
17

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sysprog21/elfuse のほかの issue

sysprog21/elfuse の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。