Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Signalfd + waitpid + multithreading

Abierto
#3,898 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
cpp, linux

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
C++
Estrellas
10.7k
Forks
666
Merge medio
2 d 13 h
PR fusionados (30 d)
33

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rr-debugger/rr

Todos los issues de rr-debugger/rr

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.