系统平台：Tina
硬件平台：R818、R329、R328、R528 …
模组：XR829、XR819S …

问题描述

客户反馈板子压测BLE扫描，不停止，bluetoothd进程RSS值一直升高。客户怀疑是内存泄露。

问题分析

1.该问题是用户一直扫描，导致RSS值升高，这个升高是合理的，因为每扫描到一个设备就会malloc一部分空间，期间不会释放该部分空间，只有在停止扫描3min后，才会一次性释放掉（bluez设计如此，3min的定时器清除暂存的扫描信息）。
2.在实际测试，会发现3min停止扫描后，RSS值并没有变小。解释：malloc时空间过小，不超过一定阈值时，是采用 sbrk方式，其在用户释放之后 ptmalloc 对这块内存进行重新管理利用，进程依然持有这块内存。其属于glibc 内存池。
3.测试1：修改M_MMAP_THRESHOLD: mmap 内存分配阈值为16B，测试到停止扫描rss的值会降低。
4.测试2：脚本压测循环打开扫描15s–关闭扫描40s。压测3天，rss值不会增加。

问题总结

该问题澄清不是内存泄漏，是bluez机制如此，等停止扫描再一起释放。释放后的内存不会立即归还系统，所以不会体现在rss值上，属于进程循环使用的内存。

解决办法

• 方式一：客户不能一直扫描，应用层要扫描一段时间后，停止扫描一下，再启动扫描，要给bluetoothd一个释放的机会。就像bluetoothctl一样，执行scan on看起来是一直在扫描，实际上是做了一个定时器，一段时间后会停止扫描，再启动扫描。

• 方式二：如果客户不通过dbus的扫描，而是通过socket直接和内核通信的。可以将bluez中关闭掉存
  储扫描到的设备信息，5.38版本不需要修改，设计就是这样，5.54及以上的版本需要修改。修改位置：
  src/adapter.c