首先使用sudo coredumpctl list | grep a.out获取core文件的信息。显示结果如下: Wed 2018-09-19 17:22:39 CST 54666 1100 0 11 * /polestar_build/home/dev/test/core/a.out 1. 从结果中知道PID是54666,可以使用sudo coredumpctl dump 54666 -o a.dump,将core文件dump到a.dump中。 core文件格式 core...
一、分析Core文件 1.1 找到core文件目录,启动mycrash:mycrash 1.2 查看崩溃的堆栈信息:bt 1.3 反汇编崩溃点的代码,10行:dis -l extract_http_info+73 10 二、分析源文件hinfo.ko 2.1 查看源文件信息:objdump -S hinfo.ko > tmp 2.2 从tmp文件中查找1.3中的内容movb $0x0,(%r12,%rax,1),即可确定代码...
thread dump是一个文本文件,打开后可以看到每一个线程的执行栈,以stacktrace的方式显示。通过对thread dump的分析可以得到应用是否“卡”在某一点上,即在某一点运行的时间太长,如数据库查询,长期得不到响应,最终导致系统崩溃。单个的thread dump文件一般来说是没有什么用处的,因为它只是记录了某一个绝对时间点的情况...
通过反汇编,然后堆栈回溯,找到出问题的函数,该方法需要熟悉汇编,其次需要耐心,这里不详述。 方法三:coredump分析法 对于死机问题,某些情况下OOPS打印出来的信息不足以分析。coreDump给了个详细的方法。 首先在内核当中打开coredup 开关,死机后就会产生一个core问题,事后可以通过 gdb调试方法来分析定位死机的位置。 摘自:...