内存泄露问题定位
The Standardization Office was revised on the afternoon of December 13, 2020
一、现象
进行24用户的常保，出现region1 bucket0的内存泄露，大概20分钟泄露1000个，保持3小时后内存耗尽，造成宕机。

二、定位方法
CCPU的内存分配机制如下：
CCPU对于内存的处理，是采用事先划分好一大块静态内存区，供软件使用。

其划分
对于内存分配，如果待分配的内存大小介于Bucket内存四种块大小之内，就使用相应的Bucket内存去分配；如果待分配的内存大小超出了Bucket内存最大块的大小，则使用Heap内存分配。

打开之前的定位内存泄露问题的宏开关，控制台出现大量打印。

无法定位问题。

经分析，每块内存的分配回收的历史信息其实没有必要保存，只需要保留最后一个分配的情况即可。

在每个块中，内存的管理其实是一个数组，用一个链表来记录未分配的内存块。

根据这个原理，在分配、回收内存时可以得到该内存块在bucket中的索引。

例如region1 bucket0有内存泄露，则分配一个10000的数组记录每个内存元素的分配回收情况。

保存该内存元素当前是分配还是回收，最后分配的文件名行号。

最后将这些信息输出到文件里。

这种方法可以用于定位任何bucket的内存泄露，并且不需要PC侧的解析工具。

经过使用该方法分析，泄露的内存都是由解析上行语音包时分配的。

三、内存泄漏原因
下面分析这些内存为什么会泄露，经过初步走读代码在出现异常又没有释放内存时增加打印，但是进行常保测试没有出现这些打印。

在申请内存和数据包到达MAC时分别进行统计，发现申请内存的次数多于数据包到达MAC层的次数。

继续走查申请内存到数据包传递到MAC之间的代码，发现当tfi=0时也会申请内存，但后续因为计算出的TB个数为0，所以并没有得到处理，从而导致内存泄露。

四、结论
当用户数较多时会收到tfi为0的上行数据包，而代码中对这种情况的处理有问题。

解决办法：在申请内存之前判断TB块总长度是否为0，如果为0则直接返回，不申请内存。