我在一些核心转储文件上运行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中).但是所有的追溯都是共同的,那就是他们结束那个烦人的? (),并且不会从“我的”代码列出任何函数名称.
我认为这与gdb在启动时打印的一些消息有关;例如,
Reading symbols from /xyz/mono/log4net.dll.so...(no deBUGging symbols found)...done.Loaded symbols for /xyz/mono/log4net.dll.soReading symbols from /xyz/mono/Contoso.Util.dll.so...(no deBUGging symbols found)...done.Loaded symbols for /xyz/mono/Contoso.Util.dll.soReading symbols from /xyz/mono/Contoso.Printing.dll.so...(no deBUGging symbols found)...done.Loaded symbols for /xyz/mono/Contoso.Printing.dll.soReading 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,因为只有当进程运行时才可用).
解决方法 当进程崩溃时,是否可以设置suspend-on-sigserv?我在谴责这是一个现场环境,所以可能是不可能的.如果可以这样做,你应该可以找到你以后的信息.
从docs:
MONO_DEBUG
如果设置,启用运行时的一些功能对调试有用.此变量应包含逗号分隔的调试选项列表.目前,支持以下选项:
…
挂起上SIGSEGV
当接收到本机SIGSEGV时,此选项将暂停该程序.这对于调试在gdb下不会发生的崩溃是有用的,因为实时进程包含比核心文件更多的信息.
总结以上是内存溢出为你收集整理的linux – Mono AOT编译程序的验尸调试全部内容,希望文章能够帮你解决linux – Mono AOT编译程序的验尸调试所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)