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

Signalfd + waitpid + multithreading

Aperta
  • Qualcosa non va?
#3,898 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
cpp, linux
Ambito
operating-systems

Direzione di ricerca

Start by cloning the linked rr-signalfd-bug reproducer and running ./run.sh to confirm the difference between normal execution and rr record. Read issue #3658, then trace the rr handling of CLONE events and subsequent signal-delivery events for tasks whose tracer uses signalfd, epoll, and waitpid. Done means the reproduced cloned-task events no longer remain asleep under recording.

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

Descrizione

This is a bug much similar to a previous one (that was fixed by @rocallahan) which can be found here, called RR waitpid bug not seen during non-recording

This time, it's instead an "awaiter thread" that uses signalfd and epoll to be notified of events (and then subsequently running waitpid as one would).

There's a test application that reproduces this bug 100% of the time here, clone the repo, and just do ./run.sh (it builds and runs without then with rr record).

Short summary of the reproducer:

a tracer application, it has a thread whose job is to be notified via signalfd on SIGCHLD that it can WAITPID. The tracee is TRACEMEd and set up to signal for most of the ptrace events.

The actual CLONE events will show up, as usual, but not the subsequent events for the cloned tasks, essentially putting them to sleep forever (since the tracer application doesn't get the SIGSTOP/SIGTRAP, whatever signal is delivered at the next signal-delivery-stop for the newly created task).

Since this test application works just fine, if no additional tracer/debugger thread is doing the epoll+waitpid-dance (i.e. done on the "main thread/task leader"), I'm guessing the solution will be very similar to that of the previous related issue #3658

Lingua principale
C++
Stelle
10.7k
Fork
666
Merge medio
2g 22h
PR unite (30g)
27

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 rr-debugger/rr

Tutte le issue di rr-debugger/rr

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.