MOCOR平台内存管理总体介绍与案例分析.pptVIP

. * * MOCOR内存bug实例分析 0x000bcc30之前的24个字节，就是该块内存的header，我们看到，next指针明显异常，说明至少next指针被覆盖了。然后再往前看，上一块内存的结束标志（END FLAG）也异常了，说明了上块内存的结束标志也被覆盖了。此外，我们再往前看，发现这两块被覆盖的内存的值，跟之前同样位置的值非常类似（都是0x02xxxxxx）。综合以上的所有现象，我们可以认为是上一块内存写越界造成内存覆盖的可能性非常大。 因为0x040bcc30是在app heap的范围，所以我们再来看app heap信息： . * * MOCOR内存bug实例分析 . * * MOCOR内存bug实例分析 可以看到，红色部分0x40bcc10开始的那一块内存，就是我们刚才确认了header被破坏的那一块内存。那么它上面的绿色那一行，就是写越界的那一块内存。这一块内存是在mmipb_wintab.c在11007行分配的。 下面我们可以有两种方法： 第一种是review 代码，找到越界的地方。因为内存分配的地方已经确定了，只要检查哪些地方会写这块内存，会不会写越界就可以了。如果代码不复杂的话，会很快找到结果。 第二种方法就是利用BM，可以用BM监控上一块内存的END FLAG地址，如果在该内存的生命期内，该地址的值被改写了，那么就会直接assert。这样可以直接定位越界的第一现场。 . * * MOCOR内存bug实例分析 2.案例二： 如果被覆盖的内存是静态内存，比如发现某些变量的值异常，可以在map里找到变量的地址，用BM来监控。 某客户项目随机出现死机： File: RTOS\source\src\c\threadx_mem.c Line: 494 ASSERT(ASSERT: Error 0x2 (Invalid pool pointer !), iram_mgr.c, line=159, param=0x8) Invalid pool pointer表明死机因为在pool上分配内存时，传入的pool结构异常。Assert后，pool的状态如下： . * * MOCOR内存bug实例分析 其中，虚线框的部分表示属于底层RTOS的部分，也就是ThreadX管理的部分。RTOS把可动态分配的物理内存资源分成了两个大的部分，一部分称之为块池(Block Pool)，另一部称为字节池（Byte Pool）。就是这两个部分，构建了整个MOCOR内存管理机制的基础部分。 从图中我们可以看出，当前内存池里已经分配了两块内存，所以一共有三个内存块。每一个内存块额外需要两个指针的空间。其中一个指向下一个内存块，另一个则作为空闲与否的标志。如是空闲内存则固定为0xFFFFEEEEUL，否则为控制块地址。 从图中我们可以看出，内存块池中的每一个内存块额外多需要一个指针的空间。当内存块已分配时，该指针指向控制块，当内存块未分配时，该指针指向下一块未分配内存，或者为NULL（是最后一块未分配内存时）。 Heap的大小可以根据具体项目的情况修改，比如如果 app heap不够用，可适当改大（不能改小）。Base heap和static heap如无特殊情况不要更改。 上面是dynamic heap的当前使用情况，其中最上的几行是heap的一些信息，包括起始和结束地址，总大小，当前可用大小，最多使用的大小等。之后就是heap里所有的内存块的信息，包括已分配的和未分配的，按物理地址的顺序排列。其中每一列的含义一望便知，不再累述。 需要注意红圈的几个地方，首先最上面红圈表示当前heap里还剩多少内存可以分配，但并不表明就有这么多连续的内存。事实上，在这个例子里我们可以看到剩余的总内存包括两块空闲内存（下面的两个红圈），而且这两块内存在物理空间上不连续，所以当前能分配的最大内存是这两块内存里较大的那一块。(如果这两块内存物理上是连续的，则可以视为一块)。 此外我们还可以看到，FREE的内存块有时还是可以看到filename和line，这可以告诉我们这块内存之前（即尚未被free的时候）是由谁分配的，但并不表明这块内存依然同这个文件有什么关系。 其他heap的使用情况也可以同样看到。 我们可以看最小的内存池是16字节，该内存池共有480个16字节的内存块(其实由于debug信息的存在，每个内存块的实际大小要比16字节大，这部分内容我们在后面详细讨论)。 其中，每一列的意义如下： Pool_Name : 内存池的名字 Start_Addr : 内存池的开始地址 End_Addr: 结束地址 Total_Num: 内存池里的内存块总数 Max_used: pool中分配block