FREESWITCH系列之内存泄漏排查总结

心路历程

1.懵逼状态

在接到这个任务的时候，对FreeSwitch处于一问三不知的情况，不了解FreeSwitch的业务，不了解流程，更要不要说代码了。但是还是硬着头皮上了，原本以为是个短期接触战，没想到被自己搞成了持久战。回过来头看，一开始对任务的难度还是低估了，没有做好持久战的准备。

2.无头苍蝇状态

在接到任务后，在没有先去了解业务的情况下，就开始了各种尝试。

工具1：valgrind，跑了一段时间后，除了输出一堆无用的垃圾外，没什么用

工具2：fmpool，开源的工具，使用该工具后，性能下降明显，需要跑较长时间，才能输出一些有用的信息

工具3：gperftool，google开源的工具，使用该工具，同样性能也下降了，也需要跑较长时间，但是输出的信息很有用。可以明显的看到泄漏路径。

但是拿到这个内存泄漏图后，不了解底层代码的情况，根本看不懂。更不要说如何修改了。

3.走了弯路

在选择内存泄漏排查工具的过程中，还是走了一些弯路。一度怀疑是内存空洞造成的内存泄漏。然后看明面上的freeswitch日志，以为是视频通话场景下，分配了大量的jitter_buffer造成的内存空洞，然后导致了泄漏。在这个方向上，浪费了很多时间。

唯一的收获是了解了apr库内存池的使用，以及排除了session和channel层内存泄漏的可能性。

4.走进sofia-sip底层

后面XX告诉我84环境freeswitch有内存泄漏的情况，用上了gperftool后，输出的内存泄漏路径都在sofia-sip库。但是底层代码没人熟悉，只能沉下来心来，去啃这块硬骨头了。

5.抓注重点

在梳理内存泄漏路径的过程中，发现sofia-sip库的内存分配是基于Home-base的内存分配机制。什么意思？就是sofia-sip库的内存分配，会先分配一个home的内存，然后需要再次分配内存的时候，通过这个home来分配，释放的时候也有home来释放。所以只要抓注su_home_new和su_home_deinit，就抓注了内向泄漏的重点了