有没有检查堆栈损坏的编程方法 [英] Is there a programmatic way to check stack corruption

问题描述

我与多线程嵌入式应用工作。每个线程分配基于其功能堆栈大小。最近我们发现，该线程之一通过定义本地变量比堆栈大小以上的阵列损坏堆栈。该操作系统是uItron。

I am working with a multithreaded embedded application. Each thread is allocated stack sizes based on its functionality. Recently we found that one of the thread corrupted the stack by defining a array of local variables that was more than the stack size. The OS is uItron.

我的解决办法，
我注册了一个定时器10毫秒，此计时器将检查堆栈损坏。

My solution, I registered a timer for 10 mS, and this timer will check for stack corruption.

堆栈腐败检验方法，
1.初始化一些独特的图案堆栈存储器（我用0x5A5A5A5A）
2.从时间检查堆栈存储器的顶部仍然是0x5A5A5A5A

Stack corruption checking method, 1. Initialize the stack memory with some unique pattern (I use 0x5A5A5A5A) 2. Check from the time if top of the stack memory is still 0x5A5A5A5A

我的问题，

有没有更好的方法来检查这种类型的损坏

Is there a better way to check this type of corruption

忘了补充，现在添加：操作系统：Itron公司，处理器：ARM9。编译器：不是海湾合作委员会（ARM9特定的处理器供应商提供）...并且在支持没有内置的堆栈检查...

Forgot to add, adding now: OS : Itron, Processor : ARM9. Compiler : Is not GCC (ARM9 specific supplied by the processor vendor)... And there is no built in support for stack checking...

推荐答案

嵌入式平台上工作时最近，我看着高和低的方式来做到这一点（这是在ARM7）。

When working on an embedded platform recently, I looked high and low for ways to do this (this was on an ARM7).

建议的解决方案是你已经想出：具有已知模式初始化堆栈，并确保从函数返回后，该模式存在。我认为同样的事情我们有了一个更好的办法和尚未有人自动化这个。回答这两个问题是否，我在，就像你做，试图找到其中的腐败是存在的挖。

The suggested solution was what you've already come up with: initialize the stack with a known pattern and make sure that pattern exists after returning from a function. I thought the same thing "there's got to be a better way" and "hasn't someone automated this". The answer to both questions was "No" and I had to dig in just as you've done to try to find where the corruption was occuring.

我也滚我自己的异常向量为data_abort等方面有关于如何回溯调用栈净一些很好的例子。这是你可以做一个JTAG调试器，打破任何时候，这些中止载体发生，然后调查堆栈。这可能是有用的，如果你只有1或2个断点（这似乎是ARM JTAG调试的规范）。

I also "rolled my own" exception vectors for the data_abort, etc. There are some great examples on the 'net of how to backtrace the call stack. This is something you could do with a JTAG debugger, break when any of these abort vectors occurs and then investigate the stack. This can be useful if you only have 1 or 2 breakpoints (which seems to be the norm for ARM JTAG debugging).

这篇关于有没有检查堆栈损坏的编程方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！