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

A fatal signal on a worker thread ends only that thread

Aperta
  • Qualcosa non va?
#476 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c, linux
Ambito
operating-systems

Direzione di ricerca

Read src/syscall/signal.c and src/syscall/proc.c to trace how a Term or Core default action stops a vCPU, then compare the main-thread and worker paths in src/core/launch.c and src/runtime/forkipc.c. Add the worker-only SIGTERM reproduction described in the issue and extend test-rlimit-cpu for worker-only SIGXCPU. Done means either signal ends the whole thread group with the expected signal status.

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

Descrizione

When a worker thread dequeues a signal whose default action is Term or Core, elfuse ends that worker and leaves the rest of the thread group running. On Linux, get_signal in kernel/signal.c calls do_group_exit for a fatal signal, so every thread in the group exits regardless of which one took it.

signal_deliver in src/syscall/signal.c returns -1 for a Term or Core default action and sets the exit code, but it does not request a group exit. The run loop in src/syscall/proc.c stops the vCPU on that -1. What happens next depends on the thread: the main thread's path in src/core/launch.c calls proc_request_exit_group whenever its run loop returns, while a worker's path in src/runtime/forkipc.c discards the return value of vcpu_run_loop, runs its robust-list and clear-child-tid cleanup, and exits alone.

RLIMIT_CPU (#475) is the case that exposes it: the sampler queues one SIGKILL at the hard limit and then returns, so if a worker dequeues it, the remaining threads run past the hard limit with nothing left to send it again. A default-action SIGXCPU at the soft limit has the same gap.

Reproduction: the main thread creates a spinning worker, then blocks SIGTERM with pthread_sigmask, sleeps, and sends kill(getpid(), SIGTERM). Only the worker can take the signal. On Linux the process dies with SIGTERM. Reading the code, elfuse ends only the worker and the main thread keeps running.

Follow-ups

  • Request the group exit in delivery: a Term or Core default action taken on any thread ends the whole thread group with that signal's status, as do_group_exit does on Linux.
  • Add a test with the reproduction above: a process-directed SIGTERM that only a worker can take ends the process with SIGTERM.
  • Extend test-rlimit-cpu with a worker-only case: the main thread blocks SIGXCPU and spins, a worker spins with SIGXCPU at its default action, and the process ends with SIGXCPU at the soft limit. A SIGKILL case cannot force the worker, since SIGKILL cannot be blocked.
Lingua principale
C
Stelle
278
Fork
31
Merge medio
2g 22h
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.