本文主要是介绍利用coredump文件分析分析设备卡死问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在应用程序异常时，如内存非法访问，越界导致程序崩溃时。Core文件将记录设备当前的堆栈信息，寄存器等值。当设备出现卡死问题时，使用主动kill掉卡死线程，使设备应用程序挂掉，生成coredump文件，这样就可以分析堆栈，查看设备具体卡主到哪里，那把锁未释放，该方法对于解决死锁问题极为方便。
1 问题描述
在系统测试过程中出现设备IE控件无法正常登陆的情况,通过ps命令发现davinci进程存在,没有出现异常崩溃的现象.通过taskShow命令发现有线程累加同时有D状态线程出现,排查如下:
第一步：通过taskShow命令查看线程的运行状态，看是否有D状态
第二步：记录出现卡住线程的id信息，以后分析堆栈时使用
第三步：选一个线程，此处选择图1中线程id为25298的ipc_sdk110011线程。然后手动让程序生成coredump文件。
第四步：在gdb调试模式下输入info thread 命令
第5步：输入t 133命令跳转到对应的栈帧中，在输入bt full命令查看堆栈信息
第6步：输入t 107 命令跳转到对应的栈帧中，在输入bt full命令查看堆栈信息
第六步：走查代码发现
在netclient_set_piccfg_v30接口实现中，首先会获取一把全局锁g_param_mutexsem，然后再执行save_devinfo_config保存数据库。由于save_devinfo_config保存数据库出现异常，而用户使用控件登陆，首先要进行用户验证，要获取全局锁g_param_mutexsem。由于g_param_mutexsem一直被ipc_sdk110011线程占用，所以IE登陆时就出现卡在现象。
对于某些C库，可以直接通过查看g_param_mutexsem信息，获取到占用该锁的线程，这样就不需要本文中记录线程id信息了。如R0平台的GLIBC版本，可以用如下图9方式获知占用锁的线程，可以看到__owner=986为占用该全局锁的线程。
这篇关于利用coredump文件分析分析设备卡死问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
