通过map文件了解堆栈分配(STM32、MDK5)--避免堆栈溢出

环境:STM32F103C8T6,MDK5

在最近的一个项目的开发中,每当调用到一个函数,程序就直接跑飞。debug跟进去看不出什么逻辑错误,但发现函数内局部变量声明之后,全局变量的值被清零,后来查看局部变量地址已经超出栈的范围,于是确定是栈溢出。如果不稍微了解一下堆栈,在开发过程中可能碰到各种奇怪的错误。

.map和startup.s文件

MAP 文件是程序的全局符号、源文件和代码行号信息的唯一的文本表示方法,它可以在任何地方、任何时候使用,不需要有额外的程序进行支持。

在MDK5中,在项目中双击Target就能自动打开.map文件。

Startup.s文件是系统的启动文件,主要包括堆和栈的初始化配置、中断向量表的配置以及将程序引导到main( )函数等。

Startup.s主要完成三个工作:栈和堆的初始化、定位中断向量表、调用Reset Handler。

堆栈作用

栈(stack)空间,用亍局部变量,函数调时现场保护和返回地址,函数的形参等。

堆(heap)空间,主要用亍劢态内存分配,也就是说用 malloc,calloc, realloc 等函数分配的变量空间是在堆上。

堆栈在内存分布

在map文件中搜索STACK或者HEAP,在接近文件底部的位置可以看到SRAM的分配,如下图。

从上图中可以看出SRAM空间用来存放:1、各个文件中声明和定义的全局变量、静态数据和常量;2、HEAP区;3、STACK区。

STM32的堆栈是存放在SRAM中的,分配堆栈大小需要考虑SRAM容量。

在.map文件中的Image Symbol Table底下可以找到如下图所示堆栈分布信息。

堆在使用时会从低地址往上加,而栈是从__initial_sp开始往下减。以上图中的堆栈地址为例,malloc会从0x20002248开始往上加,局部变量的分配会从0x20004448开始往下减。如果入栈元素过大,使得入栈元素的地址访问到了0x20002448之后的内容,就发生了栈溢出,首先会改变堆中的元素值,如果入栈元素够大,可能会直接改变HEAP后面的全局变量。同理,当动态申请的内存过大时,堆中变量越界到栈中,此时就发送堆溢出。

避免产生这类错误的产生,程序设计时就应该考虑变量大小和堆栈大小是否合适。一个是减少过大的临时变量和动态申请内存,另一个是在SRAM空间允许的情况下增大堆栈大小,如上图中栈大小是8192字节,堆大小是512。

堆栈大小设置

MDK5中可以通过修改startup.s文件来设置堆栈大小,只需要修改startup.s文件中的Stack_Size和Heap_Size即可,如下图所示。

KEIL Uvison5中默认生成的startup.s文件是只读的,无法修改,只需要设置一下该文件的属性,把只读取消即可。

原文地址:https://www.cnblogs.com/guoyicai/p/10653946.html

时间: 2024-11-07 06:25:23

通过map文件了解堆栈分配(STM32、MDK5)--避免堆栈溢出的相关文章

stm32 map文件的分析

相信有较大项目开发经验的朋友都曾遇到内存溢出的问题,那么大家都是如何分析这类问题的呢?大家遇到HardFault_Handler 有对map分析过吗? 首先讲述一下关于map在MDK-ARM中的配置.其实,在MDK-ARM中,我们可以根据自己的情况(不同配置),在map文件中输出对应(我们需要)的内容.默认情况下,输出所有信息. Project -> Options for Target -> Listing:会看到如下配置界面: 看到上图,相信都应该明白map文件大概有哪些内容了吧? map

STM8S103 解决Rom空间不足 & Map文件分析

STM8S103只有8KRom,很容易造成空间不足.对于空间不足,我们就要从map文件着手分析,究竟哪些函数占了多少空间,map文件分为几部分:Segments(总括了各个段所占的空间), Modules(各个源文件为单位,进行划分), Stack usage(堆栈使用,列出堆栈空间和堆栈深度), Call tree(函数之间的调用关系), Symbols(各个符号的起始地址和属性). 其中flash空间=".text" + ".const" + ".in

如何定位Release 版本中程序崩溃的位置 ---利用map文件 拦截windows崩溃函数

1       案例描述 作为Windows程序员,平时最担心见到的事情可能就是程序发生了崩溃(异常),这时Windows会提示该程序执行了非法操作,即将关闭.请与您的供应商联系.呵呵,这句微软的“名言”,恐怕是程序员最怕见也最常见的东西了. 在一个大型软件的测试过程中,初期出现程序崩溃似乎成了不可避免的事.其实测试中出现程序崩溃并不可怕,反而是测试的成功.作为开发的我们更需要关心的是程序中的哪个函数或哪一行导致了系统崩溃,这样才能有针对性的进行改正. 本文描述了自己总结的几种定位崩溃的办法.

VS2005(vs2008,vs2010)使用map文件查找程序崩溃原因

VS 2005使用map文件查找程序崩溃原因 一般程序崩溃可以通过debug,找到程序在那一行代码崩溃了,最近编一个多线程的程序,都不知道在那发生错误,多线程并发,又不好单行调试,终于找到一个比较好的方法来找原因,通过生成map文件,由于2005取消map文件生成行号信息(vc6.0下是可以生成行号信息的,不知道microsoft怎么想的,在2005上取消了),只能定位在那个函数发生崩溃.这里可以通过生成cod文件,即机器码这一文件,具体定位在那一行崩溃. 首先配置vc2005生成map文件和c

.map文件的作用以及在chorme下会报错找不到jquery-1.10.2.min.map文件,404 的原因

source map文件是js文件压缩后,文件的变量名替换对应.变量所在位置等元信息数据文件,一般这种文件和min.js主文件放在同一个目录下. 比如压缩后原变量是map,压缩后通过变量替换规则可能会被替换成a,这时source map文件会记录下这个mapping的信息,这样的好处就是说,在调试的时候,如果有一些JS报错,那么浏览器会通过解析这个map文件来重新merge压缩后的js,使开发者可以用未压缩前的代码来调试,这样会给我们带来很大的方便! 而这种还原性调试功能,目前只有chorme才

如何利用Grunt生成对应的Source Map文件,线上代码压缩使用chrome浏览器便于调式

首先我们来说说为何要生成sourceMap文件呢?简单的说,sourceMap是为了压缩后的代码调式提供方便,比如线上的JS文件已经压缩了,但是线上比如说有bug,但是代码已经是压缩后的,对于开发并不好调式,所以想生存一个对应的Map文件,然后使用chrome浏览器在源文件未压缩的JS文件下调式. 那么Map文件到底是什么呢?简单的来讲它就是记录信息,记录一些为压缩之前的js文件的位置,及压缩后的文件对应未压缩之前的文件,对应第几行第几列的那些代码! 在讲解使用grunt生存Map文件之前,我们

Linux System.map文件【转】

转自:http://blog.csdn.net/ysbj123/article/details/51233618 当运行GNU链接器gld(ld)时若使用了"-M"选项,或者使用nm命令,则会在标准输出设备(通常是屏幕)上打印出链接映像(link map)信息,即是指由链接程序产生的目标程序内存地址映像信息.其中列出了程序段装入到内存中的位置信息.具体来讲有如下信息: 目标文件及符号信息映射到内存中的位置. 公共符号如何放置. 链接中包含的所有文件成员及其引用的符号. 通常我们会把发送

Delphi通过Map文件查找内存地址出错代码所在行

什么是MAP文件       什么是 MAP 文件?简单地讲, MAP 文件是程序的全局符号.源文件和代码行号信息的唯一的文本表示方法,它可以在任何地方.任何时候使用,不需要有额外的程序进行支持.而且,这是唯一能找出程序崩溃的地方的救星.       如果要查找代码行号,需要使用下面的公式做一些十六进制的减法运算:       崩溃行偏移 = 崩溃地址(Crash Address) - 基地址(ImageBase Address) - 0x1000       为什么要这样做呢?我们得到的崩溃地

system.map文件详解

有时system.map文件可以帮助我们理解内核编译,它记录了所有代码的运行地址.对于系统的oop消息.或者通过gdb的调试消息,都需要根据该对照表,将内核熟悉的函数地址转化为用户熟悉的函数名称,便于用户进行故障定位.运行监控. system.map内容格式为:线性地址 类型 符号 符号类型. 小写字母表示局部; 大写字母表示全局(外部). A The symbol's value is absolute, and will not be changed by further linking.