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

Make zombie loggers logic more robust

Abierto
#848 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 5 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
cpp, ios

Línea de trabajo

Comienza con Logger::RecordShutdown en lib/api/Logger.cpp alrededor de la línea 948 y sigue la protección del logger zombi utilizada durante FlushAndTeardown. Revisa las rutas de LogManager Initialize/FlushTeardown y GetLogger, y luego considera la prueba de estrés propuesta con registro concurrente durante 100.000 iteraciones. Se considera terminado cuando la condición de carrera ya no provoca un deadlock ni un bloqueo de la terminación sin introducir un fallo.

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

Descripción

bug iOS v4

Describe your environment.

This issue is reproducible in one popular app on older models of iOS devices with slower processor.

Steps to reproduce.

Steps:

  • application exiting.
  • main thread is calling FlushAndTeardown.
  • at about the same time another thread is scheduled to perform logging on ILogger.
  • both clash with a deadlock in zombie logger protection code in Logger::RecordShutdown() method.

What is the expected behavior?

Well, it is expected that applications do not abuse the logging API that way.. At the same time we have some protection mechanism in place, to allow the safe use-after-free. Just that protection mechanism is failing at extremely low rate, unique to the concurrent-use-during-free.

What did you expect to see?

I expect:

  • the app should avoid doing what it is doing.
  • the zombie logger logic MAY be improved to handle this race condition / deadlock in zombie-logger protection code in a better way.

What is the actual behavior?

Deadlock and hang on app termination, hang in the fool-proof code that is supposed to prevent a crash due to use-after-free. As of note, the code very reliably preventing the crash ... by hanging instead. Unfortunately that hang is eventually reported as a crash.

Additional context.

The crash rate right now is extremely low. It does not seem to affect newer devices.

I think we need to add the following stress test:

  • Initialize / FlushTeardown in a tight loop on LogManager instance.
  • rogue thread(s) attempting to obtain loggers via GetLogger and log massive volumes of data
    Basic expectation here that the app should not crash after a 100,000 iterations like this. I am not sure if we can use some other fuzzy testing tools to artificially cause the deadlock.

Solution could be to perform timed-wait on mutex here:
https://github.com/microsoft/cpp_client_telemetry/blob/a924650883ecfd44f12dba131ca117f502f372b9/lib/api/Logger.cpp#L948

And when we see that the timeout happened, we return status back, and we avoid doing anything on that ILogger instance - discarding events that are timing out on that path.

Lenguaje dominante
C
Estrellas
102
Forks
67
Merge medio
5 d 5 h
PR fusionados (30 d)
8

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 microsoft/cpp_client_telemetry

Todos los issues de microsoft/cpp_client_telemetry

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.