【问题标题】:MySQL C API memory leak?MySQL C API 内存泄漏?
【发布时间】:2011-12-18 20:31:32
【问题描述】:

最近,我开始编写一个使用libmysqlclient 的C 程序。当使用valgrind 检查我的代码时,它报告了内存泄漏。以下最小代码 sn-p 重现了该行为:

#include <mysql.h>

int main(void)
{
    MYSQL* mysql = mysql_init(0);

    mysql_close(mysql);

    return 0;
}

使用valgrind 检查生成的程序告诉我:

==25614== LEAK SUMMARY:
==25614==    definitely lost: 0 bytes in 0 blocks
==25614==    indirectly lost: 0 bytes in 0 blocks
==25614==      possibly lost: 0 bytes in 0 blocks
==25614==    still reachable: 288 bytes in 3 blocks
==25614==         suppressed: 0 bytes in 0 blocks

根据 MySQL API 参考,mysql_close()...

关闭之前打开的连接。如果 mysql_init() 或 mysql_connect() 自动分配了 mysql 指向的连接句柄,mysql_close() 也会释放该句柄。

但是,valgrind 报告未释放的内存。这里有什么问题?

【问题讨论】:

  • 可能内部缓冲区初始化一次?
  • 我认为这与 valgrind 使用本地时间和朋友检测泄漏有关
  • 迈克尔:你说得对,看看我的回答。

标签: mysql c api memory-leaks valgrind


【解决方案1】:

翻阅文档,我找到了解决问题的函数mysql_library_end()

引用自 MySQL API 参考:

这个函数最终确定了 MySQL 库。您应该在使用完库后调用它(例如,在与服务器断开连接后)。

就个人而言,我觉得libmysqlclient 强迫其用户调用自己的清理函数相当烦人。 IMO,一个更好的解决方案是在连接计数降至零时自动调用mysql_library_end()

【讨论】:

  • 6 分钟可以改变
  • 不可告人:措辞问题花了我更长的时间:|
  • 我今天注意到了同样的情况,发现必须手动调用 library_end o.O 有点愚蠢
猜你喜欢
  • 1970-01-01
  • 2019-09-17
  • 2023-03-17
  • 1970-01-01
  • 2016-01-27
  • 2010-11-11
  • 2017-02-18
  • 1970-01-01
  • 2015-11-19
相关资源
最近更新 更多