OpenSSL内存泄漏之谜:重复加解密场景下EVP_CIPHER_CTX的free陷阱如何彻底规避?

各位社区大佬好,我在开发一个高性能网络代理服务时遇到了一个令人困惑的内存泄漏问题。具体场景是:使用OpenSSL 1.1.1的EVP接口进行AES-GCM加密解密,在持续运行8小时后,进程内存从初始的200MB增长到超过2GB。通过valgrind检测发现泄漏点集中在EVP_CIPHER_CTX_new()和EVP_CIPHER_CTX_free()的调用上。
核心代码逻辑:
EVP_CIPHER_CTX* ctx = EVP_CIPHER_CTX_new();
EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, key, iv);
// 执行加密操作
EVP_CIPHER_CTX_free(ctx);
奇怪的是,在单次测试中内存完全正常,但在模拟生产环境的高频调用下(每秒约3000次加解密),即使确保每次调用后都执行free,内存仍持续增长。
我怀疑问题可能涉及:
1. OpenSSL内部的内存池管理机制在多线程下的异常
2. AES-GCM模式中authenticated tag处理导致的内部缓存未清空
3. 与Linux内核的mlock机制某些冲突
已排查:确保所有错误分支都执行free、验证了线程安全锁机制、尝试过EVP_CIPHER_CTX_reset()替代free。目前临时方案是定期重启服务,但需要根本解决。是否有熟悉OpenSSL底层实现的朋友遇到过类似问题?

邀请回答 换一换
暂无数据
0 人关注

版权区

亲爱的用户欢迎您
侵犯版权/问题反馈
发送至邮箱:qitong@haihua.com.cn
Powered by 綦桐专业团队研发-luolitu.vip 0.7.1

网站备案/许可证号:鲁ICP备2021035806号

gotop
0 new message tips
title list