libcurl内存泄漏排查

由于一些第三方平台/服务的API都升级成了Https,导致原来Tars自带的Http库无法直接使用了,于是引进了libcurlgithub地址)。

但是发现在对应模块长时间运行后,其占用内存一直稳定上升,存在内存泄漏。首先排除掉一些不太可能的泄漏点:Tars、std::string、std::map、std::vector常规使用,无显式的new/malloc。

那么只剩下模块引入的动态库libcurl了,而程序实现严格按照libcurl按照官方文档的样例做法:

  1. 在主线程curl_global_init;
  2. 业务线程每次进行业务处理时调用curl_easy_init获得新的CURL,设置好选项后调用curl_easy_perform;
  3. 业务处理完毕后调用curl_easy_cleanup,curl_slist_free_all(如果有用到curl_slist)释放资源;
  4. 如果主线程退出调用curl_global_cleanup释放资源;

开始一度以为是libcurl用法有问题,后来用valgrind跑程序发现是libcurl真有泄漏,github上1W+Star的开源库有泄漏,这是什么操作?

发生泄漏时服务器环境:

系统:Centos 7.2 64位

Gcc版本:gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)

libcurl动态库版本:7.29.0(通过yum install curl & yum install libcurl-devel安装)

curl官方的Mailing Lists上面也有很多提到内存泄漏的问题,大多是围绕OpenSSL展开,也有一些只言片语提到尝试开启OpenSSL,但是本地通过valgrind测试观察异常日志,函数调用并没有进入OpenSSL相关函数,这是怎么回事?让我们找找源头:

libcurl的默认安装配置在目录/usr/lib64/pkgconfig,里面有其配置文件libcurl.pc

注意红框部分–without-ssl,原来默认OpenSSL是没有开启的。

解决步骤

1、下载libcurl,这里是下载的7.63zip安装包

2、./configure –with-ssl –libdir=/usr/lib64 –includedir=/usr/include;

3、make;

4、sudo make install;

5、相关模块重启;

步骤2的配置参数可以根据按需选择,然后观察SSL support: enabled (OpenSSL)这一栏是不是绿灯。

更新之后程序运行几天稳定,并内存占用正常。

 

最后强调一下,不同linux版本的libcurl默认配置可能不一样,这个问题与解决可能无法直接套用在其他linux版本。

(全文结束)

 


转载文章请注明出处:漫漫路 - lanindex.com

Leave a Comment

Your email address will not be published.