linux - Mono AOT 编译程序的事后调试

Question

我有一个用 C# 编写并在使用 Mono 的 Linux 系统上运行的大型程序，它偶尔会崩溃并导致 mono.bin 进程转储核心。

我在一些核心转储文件上运行了 gdb，但它不是很有用，因为回溯中没有 C# 函数的名称。根据this discussion I found :

It won't work. The information required to construct managed stack traces is contained in runtime data structures, and it is only available while the program is running. You can AOT your application, then you will have more usable stack traces.

所以，我做到了。我 AOT 编译了我所有的 C# DLL 和 EXE 文件。使用 --aot=write-symbols 选项。对于我的程序的测试版本 crashes on purpose所以我可以检查这是否使回溯更有用。而到目前为止，还没有。来自主线程的回溯看起来像:

#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)。但是所有回溯的共同点是它们以令人讨厌的 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，因为它仅在进程运行时可用。)

Answer 1

是否可以设置 suspend-on-sigserv 然后在进程崩溃时附加？我假设这是一个实时环境，所以可能无法实现。

如果你能做到这一点，你应该能够找到你想要的信息。

来自docs :

MONO_DEBUG

如果设置，启用一些对调试有用的运行时特性。此变量应包含以逗号分隔的调试选项列表。目前，支持以下选项:

...

在 sigsegv 上挂起

此选项将在收到 native SIGSEGV 时暂停程序。这对于调试在 gdb 下不会发生的崩溃很有用，因为实时进程包含的信息比核心文件更多。