Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

elfuse segfaults after a failed guest init under a host RLIMIT_AS

Aperta
  • Qualcosa non va?
#458 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, macos
Ambito
backend, operating-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
C
Stelle
275
Fork
29
Merge medio
2g 8h
PR unite (30g)
17

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sysprog21/elfuse

Tutte le issue di sysprog21/elfuse

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.