Debugowanie post mortem programu skompilowanego w Mono AOT

Question

Mam duży program napisany w języku C# i działający na systemach Linux przy użyciu Mono, który sporadycznie ulega awarii i powoduje, że proces mono.bin zrzuca rdzeń.

Uruchomiłem gdb na niektórych plikach zrzutu pamięci, ale nie było to zbyt przydatne, ponieważ ślady śledzenia nie mają w nich nazw funkcji C#. Według this discussion I found:

To nie zadziała. Informacje wymagane do utworzenia ścieżek zarządzanych są przechowywane w strukturach danych środowiska wykonawczego, a tylko są dostępne podczas działania programu. Możesz zgarnąć swoją aplikację, , a następnie będziesz mieć więcej użytecznych śladów stosu.

Tak, zrobiłem. I AOT-skompilował wszystkie moje pliki DLL i EXE. Korzystanie z opcji --aot=write-symbols. Dla wersji testowej mojego programu, która jest crashes on purpose, dzięki czemu mógłbym sprawdzić, czy to czyni śledzenie bardziej użyteczne. I jak dotąd nie. Backtrace od głównego wątku wygląda następująco:

#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 ??() 

Kolejny wątek ma:

#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 ??() 

I inne wątki wydają się być w stanie bezczynności (w nanosleep, pthread_cond_timedwait, pthread_cond_wait, sem_timedwait lub sem_wait). Ale rzeczą wspólną wszystkich śladów wstecz jest to, że kończą się tym irytującym in ??() i nigdy nie wymieniają nazw funkcji z "mojego" kodu.

Myślę, że jest to związane z niektórymi komunikatami, które gdb wydrukowały po uruchomieniu; na przykład

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 

Dlaczego wszyscy *.dll.so plików „nie znaleziono żadnych symboli debugowania”? Czy biblioteki DLL muszą być zbudowane w trybie "debugowania" czy coś takiego?

A ogólnie rzecz biorąc, czy istnieje sposób na pobranie śledzonego stosu z poziomu zrzutu pamięci Mono? (Bez użycia mono_pmip, ponieważ jest to dostępne tylko wtedy, gdy proces jest uruchomiony.)

Answer 1

Nie mam pojęcia o mono .. Ale patrząc na stacktrace pod warunkiem .. to pokazuje, że nie jest w stanie uzyskać Symbole dla mono-runtime. tutaj jest link co daje debugowanie z gdb. Potrzebujesz mono-runtime z symbolami tj. so biblioteka z symbolami ... Musisz zainstalować mono-runtime-dbg ... Możesz użyć narzędzi takich jak apt-get, yum, wget, aby go zainstalować.

mam unbuntu zainstalowany .. które znajdują się po wyjściu ....

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

Then 
$ apt-get install mono-runtime-dbg 

Mam nadzieję, że pomocne ...

Answer 2

Czy byłoby możliwe, aby ustawić suspend-on-sigserv następnie dołączyć gdy awarii procesowych ? Założę się, że to środowisko działające na żywo, więc może nie być możliwe.

Jeśli możesz to zrobić, powinieneś być w stanie znaleźć informacje, których szukasz.

Z docs:

MONO_DEBUG

Jeśli ustawione, umożliwia pewne cechy wykonywania użytecznych dla debugowania. Ta zmienna powinna zawierać rozdzielaną przecinkami listę opcji debugowania. Obecnie obsługiwane są następujące opcje:

...

zawiesić na SIGSEGV

Ta opcja będzie zawiesić program, gdy odbierany jest rodzimy SIGSEGV. Jest to przydatne do debugowania awarii, które nie występują w gdb, ponieważ proces na żywo zawiera więcej informacji niż plik core.