ach*_*ora 1 c stack memory-leaks
我观察过堆栈粉碎并阅读了有关它的帖子,就像这个Stack smashing检测到的那样.我明白它就像我们试图超越边界一样,而gcc也有预防机制.但在我的情况下,当我更改行索引以跨越边界时,其打印值为0,但是当列索引超出边界时,它会导致堆栈粉碎.
以下是包含必要评论的计划
#include<stdio.h>
void main()
{
int i,j;
i=0;
j=0;
int d[2][2]={{0,0},{0,0}};
for(i=0;i<2;i++) //**when I put i<=2 there is no stack smashing**
{
for(j=0;j<2;j++) //**When I put j<=2 there comes the stack smashing**
{
if(i==j)
{
d[i][j]=1;
}
else
{
d[i][j]=0;
}
printf("%d ",d[i][j]);
}
printf("\n");
}
}
Run Code Online (Sandbox Code Playgroud)
矩阵$ ./a.out输出(i <= 2)和(j <2)
1 0
0 1
0 0
Run Code Online (Sandbox Code Playgroud)
输出(i <= 2)和(j <= 2)矩阵$ ./a.out
1 0 0
0 1 0
0 0 1
Run Code Online (Sandbox Code Playgroud)
*堆栈粉碎检测到*:./a.out终止中止(核心转储)
是否有任何固有的限制可以超过导致基于架构的堆栈粉碎的项目数量.或者这只是随机的?任何解释都会有所帮助,因为我无法想象
堆栈粉碎检测的大多数实现都是通过函数的序言来完成的,该函数在堆栈上编写一个神奇的值(通常称为"金丝雀",如煤矿中的金丝雀).然后,函数的结尾检查魔术值是否仍然相同.正确程序中的任何内容都不能覆盖魔术值,因此如果值已更改,程序必须中断并快速终止.
程序的两个不同变体会覆盖堆栈的不同部分.其中一个碰巧覆盖了金丝雀.另一个没有.
你不走运,错误检测机制没有检测到你的程序的一个版本中的错误.没有错误检测是完美的.