La infraestructura de datos que sustenta los modelos y agentes de inteligencia artificial requiere una eficiencia extrema para procesar consultas en tiempo real. Para maximizar el rendimiento y optimizar el uso de memoria, gran parte de estos sistemas se desarrollan en C++. Sin embargo, esta elección técnica conlleva riesgos inherentes, ya que la falta de seguridad de memoria puede derivar en errores críticos. Recientemente, el equipo de ingeniería enfrentó una serie de bloqueos inexplicables en Rockset, un componente esencial para la búsqueda y analítica de datos en ChatGPT, que presentaba comportamientos anómalos como retornos a direcciones de memoria inexistentes o desalineaciones en el puntero de pila.

Ante la complejidad de estos fallos, el equipo inicialmente adoptó un enfoque de diagnóstico convencional, analizando casos individuales de forma aislada. A pesar de examinar minuciosamente los volcados de memoria (core dumps) y reconstruir la historia previa a los bloqueos, las hipótesis iniciales no lograban explicar por qué el puntero de pila se desalineaba sin una causa aparente en el código de usuario. La investigación se complicó aún más debido a la naturaleza del sistema, que utiliza señales de forma intensiva para gestionar tareas ligeras y contabilidad de tiempo de CPU, lo que llevó a sospechar erróneamente de errores en el núcleo del sistema operativo o en la gestión de señales.

El punto de inflexión ocurrió cuando los ingenieros decidieron cambiar su metodología, pasando de un análisis clínico a uno epidemiológico. En lugar de centrarse en un solo "paciente" o error, desarrollaron una infraestructura para recopilar y analizar datos de toda la población de bloqueos registrados durante el último año. Utilizando scripts automatizados para procesar y clasificar los volcados de memoria, lograron segmentar los errores en categorías claras. Este proceso reveló que lo que inicialmente parecía un único problema sistémico era, en realidad, la coincidencia de dos fallos independientes que estaban enmascarando la causa raíz.

La segmentación de los datos permitió identificar que los errores de desalineación de pila estaban confinados a un entorno geográfico y temporal específico, lo que apuntó directamente a una corrupción de hardware en un host físico concreto. Una vez identificado y retirado este nodo de la infraestructura, los bloqueos asociados cesaron inmediatamente. Este hallazgo confirmó que, en sistemas distribuidos a gran escala, la corrupción silenciosa de hardware puede imitar errores de software, dificultando enormemente su detección si no se cuenta con una visión estadística global.

El segundo problema, consistente en retornos a direcciones nulas, resultó ser una vulnerabilidad de larga data en una biblioteca de código abierto ampliamente utilizada. Se trataba de una condición de carrera presente desde hace 18 años en GNU libunwind. La capacidad de aislar este error tras resolver el problema del hardware permitió al equipo centrarse en la corrección de esta dependencia. Esta experiencia ha llevado a la empresa a mejorar sus protocolos de diagnóstico, integrando el estado de los registros en sus manejadores de señales para facilitar la identificación de problemas futuros sin depender exclusivamente de volcados de memoria complejos.