如何根据死机时的栈空间数据分析推导调用栈的情况

通过死机时刻的寄存器查看是最容易入手的;

R13是当前栈顶;R14是LinkLR;


于是就知道程序是在运行0x8055C6A的这条指令出现了问题;

这条指令是将R3的值给到PC就出错了。从前面可以看到R3是0xAA8AAAB,将这个值给到PC,考虑到是thumb指令,于是给的就是0xAA8AAAA,这确实和当前死掉的时候PC的值一样;


结果查看0xAA8AAAAA处都不是指令,都是全零的东西,怪不得会造成系统死机;


从如下可知R3值从R6得到的。


从如下查到R6的来源,那么就是g_mp3_context的位置被踩坏了;






通过linkLR知道当前执行的接口是lightduer_mp3_codec_callback;

该接口的开始会进行压栈的操作,即将R0~R6、R14压进去,由此可以知道上一步的LinkLR是指向哪里的;


根据SP的位置mp3_codec_decoder_hisr_handler的调用者是mp3_codec_request_data_to_share_buffer;


接下来mp3_codec_request_data_to_share_buffer接口也有压栈操作;


根据SP的位置mp3_codec_request_data_to_share_buffer的调用者是mp3_codec_decoder_hisr_handler;


同样的方法,检查mp3_codec_decoder_hisr_handler的压栈操作;


很明显现在LR不对了;


这是因为在mp3_codec_decoder_hisr_handler里面还有对SP的减数操作,减去了0x14;

根据SP的位置mp3_codec_decoder_hisr_handler的调用者是mp3_codec_task_main;


接下来mp3_codec_task_main接口也有压栈操作;



根据SP的位置mp3_codec_task_main的LinkLR是prvTaskExitError;


prvTaskExitError正常是不会运行到的;



于是就推算完成整个调用栈:

mp3_codec_task_main

---》mp3_codec_decoder_hisr_handler

    ---》mp3_codec_request_data_to_share_buffer

        ---》lightduer_mp3_codec_callback

            ----》因为pc指向不对引发死机;



  • 1
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
当RT-Thread空间不足,通常会出现系统运行不稳定或者死机的现象。这是因为空间不足导致无法正确保存和管理函数的局部变量、参数和返回地址,进而影响系统运行和任务切换。解决这个问题可以通过以下方法: 1. 调整任务空间:可以通过修改任务配置文件或者动态调整任务的空间大小来解决空间不足的问题。需要根据实际情况分析任务的运行情况空间的使用情况来合理地调整。 2. 减少递归调用:递归调用会消耗大量的空间,可以尽量避免使用递归或者优化递归算法,减少空间的占用。 3. 减少局部变量的使用:合理管理局部变量的生命周期和作用域,尽量减少局部变量的使用,或者使用静态变量来代替局部变量,减少空间的占用。 4. 使用动态内存分配:如果空间不足,可以考虑使用动态内存分配来代替空间,将一部分变量和数据存储在堆上,减少空间的压力。 5. 调整系统配置:可以通过配置内核参数、关闭不必要的功能或者模块来减小系统的内存占用,从而释放一部分空间。 总的来说,解决RT-Thread空间不足的问题需要综合考虑系统的整体架构和功能实现,并根据实际情况进行合理的优化和调整。只有在充分了解系统运行情况和资源利用情况的基础上,才能有效地解决空间不足的问题。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值