堆栈统计知多少？(内存泄漏、栈溢出、堆栈溢出，堆栈统计，堆栈常见bug）

是华子哥啊

已于 2024-07-16 11:31:06 修改

阅读量983

点赞数 13

分类专栏：常见缺陷问题文章标签： c语言缓存 bug

于 2024-04-17 14:17:37 首次发布

本文链接：https://blog.csdn.net/weixin_41784289/article/details/137871642

版权

常见缺陷问题专栏收录该内容

2 篇文章 0 订阅

订阅专栏

摘要

本文主要聊聊关于堆栈的内容。包括堆栈和内存的基本知识。常见和堆栈相关的bug，如栈溢出，内存泄漏，堆内存分配失败等。后面介绍软件中堆栈统计的重要性，以及如何使用工具工具软件中堆栈使用的范围，并给出在软件开发中，如何降低堆栈问题，优化堆栈的一些实践。
本文旨在抛砖引玉，欢迎留言讨论。

堆栈和内存

内存是计算机中重要的单元，而堆栈是内存中最重要的应用组成。

C语言的内存分配

在嵌入式系统中，内存通常被分为几个主要区域，每个区域存储不同类型的数据，这些区域在使用方式、性能以及目的上各不相同。关于这些区域，可以参考。

C语言的内存分配{静态内存&动态内存&堆栈}

下面主要说说堆区和栈区

堆区

堆区用于动态内存分配，程序运行时可以从堆区动态地分配和释放内存。其管理通常由程序的内存管理子系统（如C语言的malloc和free函数）负责。堆的大小和使用效率直接影响程序的性能和稳定性。堆区同样位于RAM中，因此其内容在断电后会丢失。

栈区

栈区主要用于存储局部变量、函数参数和返回地址等。栈具有后进先出（LIFO）的特性，每当调用新的函数时，函数的局部变量和返回地址就会被压入栈中，函数返回时这些数据又会被弹出。栈的使用高效但空间有限，栈溢出是嵌入式系统中常见的问题之一。

堆区（Heap Memory）和栈区（Stack Memory）有以下几个主要的区别：

管理方式：
- 栈是自动管理的，由编译器控制。当函数调用时，栈帧（Stack Frame）被自动创建和销毁。
- 堆是手动管理的，需要程序员使用特定的函数（如malloc、free在C中）来分配和释放内存。
分配和释放速度：
- 栈的分配和释放速度通常较快，因为它们是连续分配的，并且不需要复杂的内存管理。
- 堆的分配和释放速度较慢。差距的时间主要用在操作系统查找空闲内存块，并可能涉及将内存块从非连续的区域移动到连续的区域。堆上分配内存不连续也导致内存的碎片化。
内存碎片：
- 栈内存是连续分配的，通常不会产生内存碎片。
- 堆内存是动态分配的，可能会产生内存碎片，这需要定期进行内存整理（Memory Compaction）来优化性能。

堆栈统计为什么如此重要？

从上面关于堆栈的常识，我们知道堆栈的大小是有限的，堆栈对于程序运行极为重要。

在设计嵌入式系统时，合理规划和管理内存区域对于确保系统的性能、稳定性和可靠性十分重要。开发者需要根据应用的具体需求和硬件资源，做出恰当的内存使用决策。

在嵌入式系统中，堆栈用于存储函数调用时的返回地址、局部变量、寄存器状态等信息。堆栈的大小直接影响到程序的运行稳定性和性能。对于安全关键嵌入式系统而言，堆栈不足可能导致系统崩溃、数据损坏甚至安全事故。因此，合理分配堆栈大小，通过堆栈统计来优化堆栈使用，对于确保系统的可靠性和安全性至关重要。

内存管理不当，会导致内存泄露（堆泄露）。而内存泄漏可能会堆栈的不足，进而出现堆栈溢出，这些是编程中常见的错误之一，而且及其严重。对于常规的桌面级应用，这些错误发生会导致程序卡顿，甚至重启崩溃。而对于涉及生命安全和重大财产安全的关键应用系统和软件，其系统不稳定和崩溃会引发严重后果，包括产品召回、系统失效甚至人员伤亡和财产损失。

内存管理不当

下面通过一些举例说明典型的问题。
Buffer overflow（缓冲区溢出）是一种常见的安全漏洞，通常发生在当程序试图向一个固定长度的缓冲区写入过多数据时。尽管缓冲区溢出通常与堆栈溢出有所区别——前者涉及对固定大小缓冲区的写操作超出其边界，后者是函数调用和局部变量使用过多堆栈空间——但在实践中，缓冲区溢出经常导致堆栈上的数据被覆盖，因此可以视为一种堆栈不足引发的问题。

以下是一个使用C语言的示例，展示了一个简单的缓冲区溢出漏洞：

#include <stdio.h>
#include <string.h>
void vulnerableFunction(char *str)
{
	char buffer[10];	
	strcpy(buffer, str); // 不安全的拷贝，拷贝应该指定大小	
	printf("Buffer content: %s\n", buffer);
}

int main() {
	char largeData[] = "这是一个超长的字符串，远远超过了buffer的容量";
	vulnerableFunction(largeData);
	return 0;
}

在这个例子中，vulnerableFunction 函数定义了一个长度为10的字符数组buffer作为缓冲区。然后，它使用strcpy函数将传入的字符串str拷贝到buffer中。如果str的长度超过了buffer的容量（在这个例子中是10个字符），就会发生缓冲区溢出。strcpy不会检查目标缓冲区的大小，所以它会继续写入数据，直到遇到源字符串的结束符\0。

这种溢出可能会覆盖堆栈上的其他重要数据，比如其他局部变量、函数返回地址等，导致程序行为异常，甚至允许攻击者执行任意代码。

为了避免这种安全漏洞，应该使用更安全的函数，如strncpy，它允许指定目标缓冲区的最大长度，从而避免溢出：

strncpy(buffer, str, sizeof(buffer) - 1);

buffer[sizeof(buffer) - 1] = ‘\0’; // 确保字符串以null结束

这样就可以显著减少因缓冲区溢出导致的安全风险。

其他一些关于堆栈溢出的例子。

Memory Allocation Failed

当请求的内存无法被分配时发生。当请求大量内存时，可能会因为内存不足或者没有足够的连续内存导致分配内存失败。

#include <stdlib.h>
int main() {
	//分配大量内存
	int *bigArray = (int*)malloc(sizeof(int) * 1000000000);
	if (bigArray == NULL) {
	printf("Memory allocation failed\n") //内存分配失败
}
	free(bigArray);
	return 0;
}

Memory Leak

内存泄漏更准确的说法是，堆内存泄漏(heap leak)，是程序员在分配一段内存后，分配的内存未被释放且无法再次访问时发生。

#include <stdlib.h>
void leakMemory() {
	int *leak = (int*)malloc(sizeof(int) * 100);
	// 漏掉了释放操作
}

int main() {
	leakMemory();
	return 0;
}

例子中，指针leak作为局部变量，在退出leakMemory函数后，没有释放且找不到地址无法再次访问。

Stack Leak

当程序中的局部变量大量消耗栈资源，而又没有退出该函数，导致stack溢出，大量的溢出可能会导致栈的不足，从而发生overflow的情况。这种一般发生在递归函数或者函数中有大循环，其有定义局部变量，比如下面的代码

void stackLeak(int n) {
	char buffer[1024];
	printf("Leaking stack memory %d,%p\n", n, (void *)buffer);
	if(n>1)
	stackLeak(n - 1);
}
int main() {
	stackLeak(500);
	return 0;
}

在32G内存的笔记本上，运行到373次就栈溢出了。

在这里插入图片描述

Stack Frame Corruption

栈帧中是函数的局部变量和函数调用时候的相关开销。当我们对局部变量进行错误的操作时候，可能会破坏栈帧，导致函数的返回地址或其他重要数据被覆盖。举例如下。

#include <stdio.h>
void corruptStackFrame() {
	int arr[1] = {0};
	int b = 10;
	int c = 20;
	arr[1] = 0; // 故意写入数组界限之外，可能覆盖返回地址
	arr[2] = 0; // 故意写入数组界限之外，可能覆盖返回地址
	printf("b=%d c=%d\n", b, c);
}

int main() {
	corruptStackFrame();
	return 0;
}

上面的例子中，有明显的数组越界的问题。同时，由于该数组是局部变量，对数组外的数进行操作，可能会导致周边的栈帧给改写，从而导致系统崩溃。

在这里插入图片描述

当然栈帧是否被改写可能涉及很多系统的很多方面。这里不详细讨论。

历史上，许多著名的软件漏洞，如 Heartbleed、Spectre 等，都与堆栈管理不当有关。通过对堆栈进行统计，我们可以提前发现潜在的安全隐患，避免类似问题的发生。

Heartbleed 漏洞是由于 OpenSSL 库中的堆栈管理错误导致的。该漏洞允许攻击者读取内存中的敏感信息，甚至可以修改内存内容。通过对堆栈进行统计和分析，可以发现 OpenSSL 库中的堆栈使用不当，从而避免 Heartbleed 漏洞的产生。

关于heartbleed，可以参考链接了解更多

https://heartbleed.com/

堆栈统计促进软件开发和性能优化

堆栈统计不仅可以帮助开发者确定程序在运行时堆栈的使用情况，还可以指导开发者进行性能优化。通过准确的堆栈使用数据，开发者可以合理分配堆栈大小，既避免了堆栈溢出的风险，也确保了系统资源的高效利用。

性能瓶颈定位：堆栈统计可以帮助开发者快速定位应用程序中的性能瓶颈。通过分析哪些函数调用最频繁或哪些调用耗时最长，开发者可以集中优化这些热点区域，从而提高整体应用性能。
资源使用分析：它可以帮助开发者理解应用程序如何使用系统资源，例如CPU和内存。这对于识别和修复内存泄漏、过度的CPU使用等问题非常重要。
代码质量改进：通过堆栈统计，开发者可以识别代码中的不良实践或设计模式，如不必要的递归、过度复杂的函数调用等，进而重构代码以提高其可读性和可维护性。
优化决策依据：堆栈统计提供了量化数据，帮助开发团队做出基于数据的决策。这些数据可以用来确定优化的优先级，决定哪些优化措施可以带来最大的性能提升。
性能回归检测：在软件开发周期中，新的代码提交可能会引入性能回归。定期进行堆栈统计可以帮助及时发现性能下降，确保软件性能持续稳定。
用户体验提升：应用程序的响应速度直接影响用户体验。通过优化那些影响性能的关键部分，可以显著提升应用的响应速度和流畅度，从而提高用户满意度。
成本效益分析：对于需要大量计算资源的应用程序，堆栈统计可以帮助识别和优化资源密集型操作，从而减少对硬件资源的需求，降低运营成本。
总之，堆栈统计是理解和优化软件性能的强大工具。通过定期进行堆栈统计和分析，开发团队可以确保他们的应用程序运行高效，提供优秀的用户体验，并以最佳的资源使用效率运作。

人工VS工具统计

在有相关统计工具之前，嵌入式系统的堆栈都是人工统计。此举虽然可行，但是实际操作中存在许多问题和不足。

耗时耗力烧脑，对于复杂的嵌入式系统而言几乎是不可行的。
没法保证准确性，特别是在面对大量并发执行的任务和复杂的函数调用关系时，更是这样。
实时更新，则更是无法做到，每一次代码的变更，可能都需要做大量的重新统计。
工具统计除了解决上面人工统计的问题之外，还有另外两个优势。

动态分析：一些高级的堆栈统计工具支持运行时分析，能够实时监控堆栈的使用情况，及时发现潜在的堆栈溢出风险。这种一般是芯片厂家或者合作厂家提供的调试工具中。
可视化效果好。许多工具提供图形化界面，直观展示堆栈的使用情况，函数调用情况以及随着函数调用，堆栈使用的变化，帮助开发者更容易理解和分析数据。

市面上常见的堆栈统计软件

堆栈统计工具有以下几类
一类是由编译和调试工具，有芯片厂商提供的，也有第三方的。比如ARM Keil MDK，IAR Embedded Workbench等等
第二类是第三方的调试工具，GNU项目，如GNU Debugger，Lauterbach Trace32
第三类是开源堆栈工具，如Valgrind，FreeRTOS中的vTaskList
最后一类是静态分析工具。这一类以polyspace code prover为代表。

相关文章链接
Lauterbach Trace32
https://blog.csdn.net/m0_56208280/article/details/129056690
ARM Keil MDK的使用
https://aijishu.com/a/1060000000426614

polyspace code prover对堆栈的统计

前面三类堆栈统计工具，在统计堆栈使用的时候，其需要编译并运行代码，这意味着其需要定义测试激励。这也意味着，这种情况的堆栈统计是特定测试激励的，其他时候的堆栈大小则需要定义合适的测试激励。而要统计软件的最大堆栈需求，则需要设计合适的测试用例，以运行到最大使用的分支和调用。这无疑对测试用例有比较高的要求。

形式化工具Polyspace Code Prover使用抽象解释法，能够深入探测到每一层函数的调用，统计每个函数本身的局部变量消耗和因为函数调用需要的栈消耗。另外，由于形式化的方法的使用，code prover能够分析代码中的分支是否因为上下文的原因不可达。这也会影响到实际程序中堆栈的大小。

函数的最大最小局部变量使用。函数中或者条件分支中定义的局部变量可能占用的内存。
函数的最大最小堆栈使用。当函数有调用时，除了局部变量外，调用的参数等也会被统计在内；
程序的最大最小堆栈使用。当程序中有main函数或者其他的入口函数，polyspace 可以统计主入口函数的总资源，其包括了调用其他函数需要的资源。
在这里插入图片描述
polyspace能够提供函数的调用关系图，据此可以看到一个函数的入口占用的资源是由于其调用了哪些函数带来的。

如上图我们知道入口函数ps_main调用了SysTick_Handler函数，也就是堆栈使用量31是SysTick_Handler调用引发的。
在这里插入图片描述