Отказоустойчивая отладка программы, скомпилированной Mono AOT

У меня есть большая программа, написанная на С# и работающая на Linux-системах с использованием Mono, которая иногда сбой и приводит к отказу ядра mono.bin.

Я запускал gdb в некоторых файлах дампа ядра, но это было не очень полезно, потому что обратные трассы не имеют имен функций С# в них. Согласно это обсуждение, которое я нашел:

Это не сработает. Информация, необходимая для создания управляемого стека трассировки содержатся в структурах данных времени выполнения, и это только доступный во время работы программы. Вы можете использовать свое приложение, то у вас будет больше трассировки стека.

Итак, я сделал. я AOT-скомпилировал все мои файлы С# DLL и EXE. Использование опции --aot=write-symbols. Для тестовой версии моей программы, которая срабатывает специально, поэтому я могу проверить, делает ли это обратные трассы более полезными. И пока это не так. Обратный ход из основного потока выглядит следующим образом:

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

Другой поток имеет:

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

И другие потоки, похоже, простаивают (в nanosleep, pthread_cond_timedwait, pthread_cond_wait, sem_timedwait или sem_wait). Но все, что происходит во всех backtraces, заключается в том, что они заканчиваются этим раздражающим in ?? () и никогда не перечисляют имена функций из "моего" кода.

Я думаю, что это связано с некоторыми сообщениями, которые gdb печатаются при запуске; например,

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

Почему все файлы *.dll.so имеют "не найдены отладочные символы"? Нужно ли самому создавать библиотеки DLL в режиме "отладки" или что-то в этом роде?

И в целом, есть ли способ получить трассировку управляемого стека из дампа ядра Mono? (Без использования mono_pmip, потому что это доступно только при запуске процесса.)

Ответы

Ответ 1

Можно ли установить suspend-on-sigserv, затем присоединить, когда процесс выйдет из строя? Я полагаю, что это живая среда, поэтому может быть невозможно.

Если вы можете сделать это, вы сможете найти информацию, которую вы после.

Из docs:

MONO_DEBUG

Если установлено, позволяет использовать некоторые функции среды выполнения для отладки. Эта переменная должна содержать список параметров отладки, разделенных запятыми. В настоящее время поддерживаются следующие параметры:

...

приостанавливать-на-SIGSEGV

Эта опция приостанавливает выполнение программы, когда получен собственный SIGSEGV. Это полезно для отладки сбоев, которые не выполняются под gdb, поскольку в реальном времени процесс содержит больше информации, чем основной файл.

Ответ 2

Я понятия не имею о моно... Но от взгляда на stacktrace, предоставленного.. он не смог получить Символы для моно-runtime. здесь , которая дает отладку с помощью gdb. Вам нужно моно-runtime с символами, то есть so библиотека с символами... Поэтому вам нужно установить mono-runtime-dbg... Вы можете использовать инструменты, такие как apt-get, yum, wget для его установки.

У меня установлен unbuntu.. который показывает следующий вывод....

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

Then
$ apt-get install mono-runtime-dbg

Надеюсь, вы сочтете это полезным...