Debug post-mortem di un programma compilato Mono AOT

Question

Ho un grande programma, scritto in C# e in esecuzione su sistemi Linux usando Mono, che occasionalmente si blocca e causa il processo mono.bin per eseguire il dump del core.

Ho eseguito gdb su alcuni dei file di dump di base, ma non è stato molto utile perché i backtrace non hanno i nomi delle funzioni C# in essi. Secondo :

Non funzionerà. Le informazioni richieste per costruire le tracce dello stack gestito sono contenute nelle strutture dei dati di runtime e sono disponibili solo durante il funzionamento del programma. . È possibile AOT l'applicazione, quindi si avranno più tracce di stack utilizzabili.

Così, l'ho fatto. I AOT-compilato tutti i miei file DLL e C# DLL. Utilizzando l'opzione --aot=write-symbols. Per una versione di prova del mio programma quella crashes on purpose così ho potuto verificare se questo rende le backtrace più utili. E finora, non è così. Il backtrace dal thread principale si presenta come:

#0 0xb7fc8402 in __kernel_vsyscall() 
#1 0x00556df0 in raise() from /lib/libc.so.6 
#2 0x00558701 in abort() from /lib/libc.so.6 
#3 0x080e59b5 in ??() 

Un altro thread ha:

#0 0xb7fc8402 in __kernel_vsyscall() 
#1 0x005f6753 in poll() from /lib/libc.so.6 
#2 0xb6f735a7 in Mono_Unix_UnixSignal_WaitAny() 
    from /opt/novell/mono/lib/libMonoPosixHelper.so 
#3 0xb5416578 in ??() 

E altri thread sembra essere stato di inattività (in nanosleep, pthread_cond_timedwait, pthread_cond_wait, sem_timedwait o sem_wait). Ma la cosa che tutti i backtrace hanno in comune è che finiscono con quel fastidioso in ??(), e non elencano mai nomi di funzioni dal "mio" codice.

Penso che questo sia correlato ad alcuni messaggi che gdb hanno stampato all'avvio; per esempio,

Reading symbols from /xyz/mono/log4net.dll.so...(no debugging symbols found)...done. 
Loaded symbols for /xyz/mono/log4net.dll.so 
Reading symbols from /xyz/mono/Contoso.Util.dll.so...(no debugging symbols found)...done. 
Loaded symbols for /xyz/mono/Contoso.Util.dll.so 
Reading symbols from /xyz/mono/Contoso.Printing.dll.so...(no debugging symbols found)...done. 
Loaded symbols for /xyz/mono/Contoso.Printing.dll.so 
Reading symbols from /xyz/mono/Contoso.LegacyDataConverter.dll.so...(no debugging symbols found)...done. 
Loaded symbols for /xyz/mono/Contoso.LegacyDataConverter.dll.so 

Perché tutti i file *.dll.so sono "senza simboli di debug trovato"? Le DLL stesse devono essere costruite in modalità "debug" o qualcosa del genere?

E più in generale, c'è un modo per ottenere la traccia dello stack gestito da un core core dump? (Senza utilizzare mono_pmip, perché è disponibile solo quando il processo è in esecuzione.)

Answer 1

Non ho idea di mono .. Ma guardando lo stacktrace fornito .. mostra non è possibile ottenere i simboli per il runtime mono. Ecco link che fornisce il debug con gdb. È necessario il runtime mono con simboli i.e so libreria con simboli ... Quindi è necessario installare mono-runtime-dbg ... È possibile utilizzare strumenti come apt-get, yum, wget per installarlo.

ho Unbuntu installato .. che mostra output seguente ....

$ apt-cache search mono-runtime-dbg 
mono-runtime-dbg - Mono runtime, debugging symbols 

Then 
$ apt-get install mono-runtime-dbg 

spero vi sia utile ...

Answer 2

Sarebbe possibile impostare suspend-on-sigserv quindi fissare quando si blocca il processo ? Sto dicendo che questo è un ambiente live quindi potrebbe non essere possibile.

Se riesci, dovresti riuscire a trovare le informazioni che cerchi.

Dal docs:

MONO_DEBUG

Se impostato, abilita alcune funzioni del runtime utili per il debug. Questa variabile dovrebbe contenere un elenco separato da virgole di opzioni di debug. Attualmente, sono supportate le seguenti opzioni:

...

sospendere-on-SIGSEGV

Questa opzione sospendere il programma quando viene ricevuto un SIGSEGV nativo. Questo è utile per il debug degli arresti anomali che non si verificano in gdb, dal momento che un processo live contiene più informazioni di un file core.