Un equipo de ingeniería de Buildkite narra cómo una serie de tests intermitentes en su suite de integración continua terminó revelando un bug de corrupción de memoria en la biblioteca redis-client (gema ruby basada en hiredis). El detonante fue una actualización rutinaria de la gema Redis un viernes; dos días después, varios tests del suite de features empezaron a fallar de forma esporádica y, con el tiempo, también se observaron caídas en los WebSockets en entornos de desarrollo. La hipótesis inicial de una race condition entre ActionCable y Redis resultó ser un callejón sin salida. La pista decisiva llegó tras varios días de depuración, cuando un test provocó un error de "double free" en malloc y otro build generó un segmentation fault cuyo core dump quedó adjunto al artefacto gracias a un plugin desarrollado previamente por otro ingeniero. El análisis del volcado mostró un tamaño de memmove de unos 45 petabytes, evidencia de corrupción de memoria. Reconstruyendo el caso con Ruby compilado con AddressSanitizer, se identificó un heap use-after-free: hiredis usa dos hilos por conexión (lector y escritor) y, en ciertos escenarios, el hilo lector liberaba el buffer del escritor. Una vez localizado el origen, la solución consistió en desactivar la extensión C de hiredis en test, desarrollo y producción, y reportar un test reproducible al repositorio upstream redis-rb/redis-client. El caso ilustra el valor de invertir en herramientas internas (subida de core dumps, Test Engine), del trabajo en equipo y, en buena medida, de la suerte para resolver bugs no deterministas cuya causa precede a su manifestación.
Noticias agregadas con IA