使用LibreSSL libtls时，tls_init()分配的内存能否释放？

我来给你梳理下这个问题～

首先明确结论：目前LibreSSL的libtls库并没有提供对应tls_init()的官方清理函数，你用valgrind检测到的那些“仍可访问”内存，是库初始化时分配的全局共享资源，设计上就是留存到进程结束的，不会主动释放。

具体细节说明： #

• 为什么会出现这些内存？
  tls_init()会加载一系列进程级的全局资源，比如默认证书存储、密码套件列表、加密算法的基础数据结构等等。这些资源是整个进程内所有libtls调用共享的，LibreSSL的设计逻辑里认为进程退出时操作系统会自动回收这些内存，所以没有提供显式的销毁接口。

• 和OpenSSL的差异
  OpenSSL的SSL_library_init()（现在更推荐用OPENSSL_init_ssl()）配套有OPENSSL_cleanup()函数来清理全局资源，这是两者设计理念的区别——OpenSSL提供了更细粒度的资源管理，而libtls走的是简化API路线，省略了全局资源清理的步骤。

如何降低对自身内存排查的干扰？ #

既然没法让libtls主动释放这些内存，咱们可以从valgrind的检测层面入手：

• 编写valgrind压制文件（suppression file）：把libtls初始化产生的“仍可访问”内存标记为无害。比如创建一个libtls.supp文件，内容示例如下：

  {
      libtls_init_memory
      Memcheck:Leak
      match-leak-kinds: reachable
      fun:malloc
      ...
      fun:tls_init
  }
  

  然后运行valgrind时加上--suppressions=libtls.supp参数，就能过滤掉这些无关的内存报告。
• 隔离测试：把自己的业务代码和libtls初始化操作分开测试。比如单独测试你的模块时，避免调用tls_init()；或者在测试脚本中先完成libtls初始化，再聚焦检测自己代码的内存使用情况，这样就能排除库的干扰。

内容的提问来源于stack exchange，提问作者rexroni