ChatGPT è crollato per colpa di due bug

Un bug di 18 anni in GNU libunwind e un processore difettoso su Azure hanno causato il crash

Hai presente quando chiedi a ChatGPT di riassumere una discussione di lavoro e, dopo qualche secondo di silenzio, ti risponde con una frase a metà, come se qualcuno avesse staccato la spina? Ecco, per mesi OpenAI ha combattuto con un fantasma esattamente così. Un errore che sembrava un banale crash, ma che in realtà stava corrodendo da dentro l’infrastruttura dati scalabile di OpenAI, quella che permette a ChatGPT di frugare tra le tue conversazioni e i documenti caricati.

La soluzione non era un semplice update: è stata una caccia al tesoro dentro un pantano di codice C++, segnali Unix e un processore difettoso.

La voce sintetica che ti risponde con calma è solo la superficie. Sotto, ogni richiesta attiva un gigantesco castello di carte. Basta che una carta traballi — un indirizzo di memoria sbagliato, un puntatore che impazzisce — e l’incantesimo svanisce. ChatGPT non è un monolito magico: è una creatura fatta di migliaia di componenti che dialogano in tempo reale. E uno di questi, Rockset, il sistema di ricerca di ChatGPT, ha tenuto in scacco gli ingegneri per settimane. Le richieste andavano in crash apparentemente a caso, ma sempre dentro il metodo DocumentTree::updateDocument. Un incubo per chiunque abbia mai debuggato codice non suo.

Il sintomo era surreale. Una normalissima funzione C++ finiva il suo lavoro, ma nel momento di passare la palla al chiamante, il programma veniva ucciso. La CPU si ritrovava a seguire l’indirizzo di ritorno fasullo. A volte nel punto dove avrebbe dovuto esserci quell’indirizzo c’era il puntatore a zero nello stack. Altre volte era lo stack pointer sballato di 8 byte, come se il processore avesse fatto un passo falso mentre camminava. Col senno di poi, era il segnale inequivocabile di una guerra sotterranea in corso.

Un bug che compie 18 anni e si nasconde nei tuoi segnali

I sospetti iniziali cadevano sulla gestione della memoria in C++, notoriamente priva di reti di sicurezza. Se scrivi in un’area di memoria che non ti appartiene, il disastro è garantito. Ma qui il disastro avveniva sempre al momento del return, un dettaglio che non quadrava. Fino a quando qualcuno non ha acceso un faro su l’uso massiccio dei segnali Unix che Rockset attiva. Per motivi di performance, OpenAI bombarda i suoi processi con il segnale SIGUSR2 a intervalli regolari. È lì che si annidava la prima parte della risposta.

Aspetta, perché nessuno si era accorto di un baco in una libreria usata da tutti, GNU libunwind, che gestisce lo srotolamento dello stack? Perché quel bug aspettava lì, silenzioso, un bug di 18 anni in GNU libunwind, capace di corrompere lo stack solo in precise condizioni di corsa tra segnali e thread. Un problema già scritto nel codice due decenni fa, attivato dalla pressione estrema del traffico odierno. Ma non bastava ancora.

Quando il problema non è solo tuo, ma del ferro che affitti

Mentre gli sviluppatori analizzavano i dump della memoria, qualcosa non tornava. Le corruzioni seguivano uno schema troppo specifico per essere solo sfortuna statistica. L’indagine ha presto puntato verso l’host fisico. Su una macchina virtuale di Azure, la corruzione hardware su Azure faceva saltare i bit in modo del tutto trasparente al sistema operativo. Un processore difettoso, roba che il tuo cloud provider non ti dice se non alzi la voce. Due bug distinti, uno software e uno hardware, che insieme mimavano un errore casuale del programma.

L’incidente non è un’eccezione: è la regola nascosta dietro ogni demo.

Pensiamo agli assistenti vocali di domani. Google ha appena costruito lo speaker Google Home per Gemini, un dispositivo capace di sostenere conversazioni complesse, gestire più richieste alla volta e ricordare quello che hai detto prima. Ti sembra magia, ma sotto il cofano c’è un’integrazione di pipeline altrettanto fragili. La differenza è che l’assistente, se sbaglia un puntatore, non ti stampa un criptico core dump sullo schermo: semplicemente, in quel momento, smette di ascoltarti.

E non è un problema solo dei big. La community ha messo in piedi una pipeline vocale straordinaria che unisce la pipeline con Nvidia Parakeet e Cerebras, l’inferenza ultraveloce di la demo di Hugging Face e Cerebras con Gemma 4 e la sintesi vocale di Alibaba. Il risultato è una voce in tempo reale che risponde quasi come un umano. Eppure, anche lì, ogni passaggio di memoria, ogni segnale scambiato tra i componenti, è un potenziale punto di rottura. La ricerca più recente su il trasferimento negativo ci ricorda che più compiti aggiungiamo a queste macchine, più rischiamo di vederli collidere invece di collaborare. Avere un modello che parla e cerca insieme è un miracolo ingegneristico, ma i miracoli richiedono manutenzione eroica.

La prossima risposta che aspetti

La prossima volta che chiedi al tuo assistente di ricordarti la password del Wi-Fi o di aggiungere il latte alla lista della spesa con un tono di voce perfetto, ricorda cosa balla dietro le quinte. Non è un’intelligenza placida e onnisciente, ma un groviglio di puntatori, segnali e chip che possono tradirti senza preavviso. L’incidente di OpenAI non dimostra che l’AI è debole: dimostra che è tenuta in vita da artigiani del codice, da chi passa le notti a interpretare i crash interni al servizio Rockset e a correggere errori nati quando ancora non esistevano gli smartphone.

Il futuro che ci aspetta non è fatto di app perfette, ma di neuroni sintetici che imparano a convivere con le catastrofi. Il nuovo speaker Google, che già oggi è in grado di ricordare le conversazioni, sta costruendo un rapporto di fiducia con noi proprio sulla rimozione di queste fragilità. E la prossima sfida sarà rendere la manutenzione invisibile tanto quanto lo è già la voce. Fino ad allora, ogni “Non ho capito, puoi ripetere?” sarà il ricordo di un processore che, per un millisecondo, ha smarrito la strada di casa.