指针过界引起全局变量改变的错误

只看该作者 · 2016-3-22 23:07

指针过界引起全局变量改变的错误

最近，在写程序的时候，碰到一个在自己看来非常不可思议的问题。当然，或者高手就觉得大惊少怪了，呵呵。

　　以下是问题相关：

　　平台：MEGA64;

　　编译环境：codeVisonAVR；

　　问题：一个全局变量在定义的时候直接赋值为0，但在程序运行过程中，没有改变该变量的操作，可是奇怪的是，程序在运行一段时间之后，这个全局变量居然自动改变了。

　　发现问题之后，我很难理解，一直无法找到原因。

　　一开始，我就怀疑是不是哪里的存储空间溢出重叠了，但由于对各种变量的存储位置，不是十分的了解，也就没有再对此做更深层的探究；其次，我怀疑是不是哪里的指针跳错了，跳到全局变量那里，造成全局变量的改变，不过对于这一点，我又自认很仔细的检查了程序，的确没有发现指针跳错的地方。

　　现在看来，其实，我的两个怀疑，都和指针有关的。

　　后来，和志刚讨论一下，他一开始就提出：是不是堆设置不够。他说的堆是指hardware stack，我一开始不知道什么是hardware stack的。我猜他的意思是说，用于程序返回堆栈的空间太小了，以至于，硬件堆栈溢出，覆盖了全局变量，自然造成全局变量的改变。

　　一开始我没有弄懂他的意思。明白之后，我觉得很有可能，不过，仔细看编译结果，又大概可以排除这个可能了，以下是编译结果：

Bit variables area: 2h to 2h
Bit variables size: 1 byte(s)

Data Stack area: 100h to 4FFh
Data Stack size: 1024 byte(s)
Estimated Data Stack usage: 98 byte(s)

Global variables area: 500h to 5DCh
Global variables size: 221 byte(s)

Hardware Stack area: 5DDh to 10FFh
Hardware Stack size: 2851 byte(s)

　　从最后一行可知，硬件堆栈大得很，4K的SRAM，已占2.8K。一般来说，就算是函数多层嵌入也不可能占如此之大的空间，网上说，就算浮点函数，40B都已经足够。

　　不过，由于志刚的提示，让我注意到上面的编译结果，以前我不知道全局变量是怎样存储的，现在就明白了，上面倒数3、4行，就是说全局变量的。可见，全局变量是保存在数据堆栈与硬件堆栈的中间，刚才志刚说，可能硬件堆栈溢出，造成全局变量的改变。虽然在这里这个可能不大了，但是，同理，会不会是数据堆栈溢出，造成全局变量的改变呢？因为，由上面几行编译结果可知，全局变量正处于数据堆栈和硬件堆栈之间，两者的溢出皆有可能造成全局变量的改变。不过，“Estimated Data Stack usage: 98 byte(s)”，这里又很明显提示，估算的数据堆栈实际用到的大小只有98B，也远远小于1024B。

　　所以说，不管是数据堆栈还是硬件堆栈，两者都很难简单的溢出。

　　下面是我在codeVisionAVR的帮助文档上面找到关于RAM的结构图：

　　可知，codeVisionAVR是如何分配SRAM的（其它编译器，各不相同的），这里简单述说，以备以后参考。以maga64为例。（芯片资料说的4K SRAM，是不包括地址前面的100B的，也就是说SRAM的大小从数据堆栈开始数起）

　　首先是，32个工作寄存器+64个I/O寄存器，这里占了RAM地址分配的前100字节，0H-99H；

　　其次是，数据堆栈，而且是由高往低堆的，也就是，先从地址高处往低处进栈，由于它是用Y寄存器来做数据堆栈的指针的，所以，数据堆栈就从Y的初始值开始，到地址100H结尾，这个大小可以在编译器工程设置里面设置，一般可以先编译程序，看编译估算的实际数据栈使用大小，再去定数据堆栈的大小，自然要定大一点，防止溢出。主要用于动态储存局部变量、函数参数和中断时各工作状态寄存器的值；

　　接着是，全局变量区域，这个是编译器通过统计程序的全局变量数量而定的。用于保存全局变量；

　　再接着是，硬件堆栈，以SP初始值开始，到全局变量最高地址为止，而且和数据堆栈一样，也是由高往低堆的。用于保存函数返回地址;

　　最后是，堆（heap），是malloc, calloc, realloc and free等链表函数用来建立链表的内存空间，如果不使用这个函数，必须设置为0.

　　由上面可知，由于全局变量处于数据堆栈和硬件堆栈中间，而后两者都是由高往低进栈的，所以说，如果正常溢出，只能是硬件堆栈溢出才可以造成全局变量的改变，而数据堆栈的溢出不可能造成这个问题。可是现在硬件堆栈这么多，也几乎不可能是它溢出造成这个问题的。

　　那会是什么原因造成上面那个问题的呢？分析之后，我重新再仔细查找程序，最后还是找到了原因。还好，这些程序原先不是我写的，呵呵。

　　有一个以数组的地址指针为参数的函数example(char *pTemp)，主函数调用它的时候，传一个4位数组temp[4]给它，如：example(temp);

　　下面大略的代码：

　　main()

　　{

　　　　char temp[4];

　　　　example(temp);

　　}

　　length[]={1,2,4};

　　example(char *pTemp)

　　{

　　　　cLength=length[getIndex()];

　　　　for(i=0;i<clength;i++)

　　　　{

　　　　　　*pTemp=readvalue();

　　　　　　pTemp++;

　　　　}

　　由于length是一个3位数组，如果getIndex()的值大于2，就造成cLength得到的值不在{1,2,4}内，而是储存length[]={1,2,4}往后地址的值，这个值是不确定的，很有可能是远远大于4。这样就造成，for里面的循环次数远远大于4次，因为，指针*pTemp本来指向一个4位的数组temp[4]，现在由于pTemp++超过3次，已经不是指向temg[]这个4位数组了，而是大于temp[4]地址的地址了。

　　我们知道，这个temp[]是一个局部变量，它应该保存在SRAM的数据堆栈里面，而数据堆栈是由高往低进栈的，紧挨着的就是全局变量区域，这个temp必定就是保存在离全局变量区域不远的数据堆栈里面。于是，只要for的次数够大，它不但改变了比temp后进的数据堆栈的数据，而且，跨过数据堆栈与全局变量区域的界限，直接修改了全局变量的某些值！

　　其实，原来写这个程序的人，已经做个防止getIndex()大于2的处理，可是呢，悲剧的是length[]却少了一位数。呵呵，好在我究竟还是数了数它的位数（在实际的那个程序里，这个数组的位数自然不会是3位这么少，这样一眼就可以看出来少不少。）。不过，如果不是志刚的提示，让我提起心思去了解存储空间的问题，即使我数出来位数少了一位，也不一定知道问题的根本原因所在！

　　其实，这里就是指针惹的祸。不怪人家说，指针是C、C++的灵魂啊——你知道，灵魂这东西，虽然有可能是个天使，也有可能是个恶魔。