Il lato oscuro - Il blog di Alessandro Catorcini

Autopsia di un'applicazione - Terza puntata: l'applicazione che si congela

Alessandro Catorcini — Tue, 08 Apr 2008 07:08:00 +0100

Se diagnosticare perch� un'applicazione si pianta non � sempre facile, diagnosticare perch� un'applicazione si congela o va in un loop infinito non lo � praticamente mai. Ci sono due ragioni fondamentali per un application hang:

un loop infinito
un deadlock

mentre individuare il primo � relativamente semplice se avviene nel vostro codice - basta attaccare un debugger, fare un break e leggere lo stack-trace, individuare un deadlock di solito richiede riti voodoo e interventi del mago di fiducia.

Se la fattucchiera non � disponibile, si possono usare altri tool pi� pratici nell'arsenale del managed developer.

Deadlock: cos'�?

Per avere un deadlock una serie di condizioni deve essere verificata allo stesso tempo:

il processo ha pi� di un thread
tutti i thread possono accedere a tutte le risorse
le risorse possono essere acquisite da un solo thread alla volta

Il deadlock avviene quando un thread A prende possesso della risorsa 1 (per esempio un socket handle di rete), mentre il thread B prende possesso della risorsa 2 (per esempio un handle di file); se a questo punto il thread A cerca di acquisire la risorsa 2 e il thread B cerca di acquisire la risorsa 1, entrambi i thread si sospenderanno in eterno aspettandosi l'un l'altro.

Anche se la condizione teorica sembra complessa, i deadlock capitano pi� spesso di quanto sembri. Guardiamo con attenzione le condizioni:

un processo ha pi� di un thread. Anche se sembra una cosa banale, ogni applicazione scritta con .NET ne ha almeno tre: l'execution thread, il GC thread e il finalizer thread. Se poi si usano timer, c'� anche un timer thread.
tutti i thread possono accedere a tutte le risorse. Questa condizione � vera a meno che non sia applicata una policy nel codice del processo (con eccezioni, come l'STA thread per la UI e la message pump)
Molte risorse non sono intrinsecamente condivisibili (per esempio un file in scrittura)

Se sospetti che la tua applicazione stia esibendo un comportamento compatibile con un deadlock, puoi provare ad usare un tool che Joe Duffy ha scritto usando le hosting API del CLR.

Uno dei comportamenti che possono essere personalizzati tramite queste API � che l'host nativo del CLR pu� essere notificato ogni volta che un thread � creato, distrutto, sospeso o messo in condizione di essere eseguito. Questo tool, crea un log dei thread presenti nel processo ed esegue un algoritmo di deadlock detection ad ogni cambiamento di stato. Se un deadlock viene identificato, l'host solleva un'eccezione critica che pu� essere catturata se il processo girava con un debugger attaccato. In questo modo si viene allertati nel momento in cui avviene la presa del lock che genera il deadlock e si pu� intervenire sul codice.

Il tool e l'eccellente articolo che lo accompagnano si possono scaricare seguendo questo link per l'articolo�e questo per il codice

I lettori attenti avranno notato che ho glissato elegantemente sul caso dei loop infiniti nel codice non vostro. Questo � il problema peggiore e sar� oggetto di un post futuro.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5

Autopsia di un'applicazione - seconda puntata gli MDA (Managed Debug Assistants)

Alessandro Catorcini — Sun, 06 Apr 2008 00:43:00 +0100

A partire dal .NET Framework 2.0, abbiamo introdotto un nuovo strumento per il debugging dei problemi tradizionalmente difficili da diagnosticare.

I cosiddetti MDA (Managed Debugging Assistants) consentono di trattare alcune condizioni come eccezioni cos� da dare l'opportunit� di attaccare un debugger.

Per avere la lista completa degli MDA fate riferimento a questa pagina su MSDN: Diagnosing Errors with the Managed Debugging Assistants

Giusto per dare un'aneddoto che mostra la potenza degli MDA, concentriamo l'attenzione su invalidOverlappedToPInvoke.

Nel 2005, quando le date per il release to manifacturing (RTM) di Visual Studio 2005 e SQL Server 2005 stavano avvicinandosi rapidamente, eravamo alla dispearata ricerca delle cause di un numero anomalo di NT Heap corruptions che lo stress testing stava trovando. Dopo uno stillicidio di due mesi, decidemmo di dedicare l'intero reliability team di entrambi i prodotti a scovare il colpevole. Dopo quattro settimane di immersione full time in memory dump e stack traces, la causa fu trovata in un'innocente funzione che faceva I/O sulla rete attraverso un I/O completion port.

Questo meccanismo dell'OS consente di trasferire il controllo dell'operazione ad un kernel thread e gestisce il messaging con l'applicazione chiamante. I dati sono scambiati attraverso una struct OVERLAPPED allocata dal caller in user mode e scritta dal kernel thread.

Il codice che aveva causato il patatrac non aveva fatto nulla di terribile, ed era formalmente corretto (motivo per cui non lo avevamo trovato immediatamente). L'unico problema era che la struttura OVERLAPPED era allocata sulla GC heap e non era pinned. Questo faceva s� che in certi casi la struttura venisse processata dal garbage collector prima che l'operazione di I/O potesse finire. Quando questo succedeva, il kernel thread scriveva sull'NT Heap handle che gli era stata passata, ma questa memoria era nel migliore dei casi free memory nel GC Heap o qualche altro oggetto (da cui le corruption).

Dopo questa avventura, introducemmo questo MDA, che genera un'eccezione a runtime ogni volta che una struttura OVERLAPPED allocata tramite P/Invoke � passata ad un kernel thread ed � raccolta dal garbage collector prima del tempo.

Per cui, se la vostra applicazione vi sta facendo impazzire e le avete provate tutte, forse un semplice

�Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework] "MDA"="1"

�

Pu� essere utile.

�

A presto

�

--Alessandro

Tags: .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, .NET Framework

Autopsia di un'applicazione - prima puntata

Alessandro Catorcini — Thu, 06 Mar 2008 07:14:00 +0100

Vorrei spendere qualche tempo per parlare di diverse tecniche di diagnosi di un'applicazione. In questa serie di post cominceremo ad analizzare le ragioni per le quali un'applicazione scritta usando il .NET Framework si pianta, presenter� alcuni esempi e pattern che possono causare quei comportamenti e mostrer� alcune tecniche diagnostiche per risalire alle cause prime di problemi profondi (interop signature mismatch e data corruption) molto difficili da diagnosticare con i tool usati comumente.

La prima puntata � una chiaccherata sulle ragioni di morte di un processo che contiene in CLR.

Qualche anno fa, quando si scriveva in C o C++ era facile piantare un programma. Bastava dimenticarsi di assegnare a null un puntatore assegnato a qualcosa che era stato deallocato e il tuo programma si piantava nel modo pi� creativo. Oggi � molto pi� difficile trovarsi un una situazione dove un'applicazione scritta nei Framework del XXI secolo sia cos� fragile.

Quando un'applicazione scritta usando il .NET Framework si pianta, succede uno dei seguenti eventi ritenuti catastrofici dal runtime (in ordine di probabilit�):

Un'eccezione sollevata nel codice non � stata gestita
Si � verificata una access violation nell'interop (cio� sei andato a leggere memoria che non � tua)
1. causata dal codice nativo eseguito
2. causata da un errore nel codice di marshalling (signature sbagliata, convenzioni di allocazione non rispettate tra caller e callee, etc.)
3. heap corruption causata da codice nativo
Una risorsa critica per l'esecuzione del programma non � disponibile. Quando questo succede, spesso il programma ha un leak di risorse native (le alloca e non le rilascia mai) o un cattivo uso del Dispose Pattern che lo portano ad una morte prematura per soffocamento. Le risorse la mancanza delle quali pu� uccidere il processo sono
1. Memoria
2. System Handles
Stack overflow (raro - pu� succedere se si esagera con la profondit� di una query o di una ricorsione)
Un bug nel CLR che causa una access violation (se ne trovate uno dopo il CLR V2 vi pago da bere :-) )

�

La domanda fondamentale � "Perch� un processo viene distrutto in questi casi".

La risposta � di una semplicit� disarmante:"Perch� � l'unica azione che garantisce la correttezza dell'elaborazione e il pi� possibile l'integrit� dei dati". Se si continua l'esecuzione in questi stati, � garantito che alcuni degli invarianti che il programmatore ha posto come ipotesi per il funzionamento dell'applicazione sono stati violati.

In questo caso sia per ragioni di correttezza sia di sicurezza, il comportamento pi� sicuro per l'applicazione � terminare il processo e generare un dump utile per scoprire cosa � andato storto.

Questa considerazione � la ragione dietro alla decisione di cambiare il comportamento di default del runtime in caso di una eccezione non gestita. Mentre .NET 1.1 consente di proseguire, .NET 2.0 e superiori termina il processo a meno che non si setti un parametro di configurazione esplicitamente.

La prossima volta parleremo di MDA (Managed Debugging Assistants) uno strumento potente e poco conosciuto per la diagnostica di problemi seri e difficili da identificare altrimenti.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Pattern