MySQL连接数据库函数内存泄露解决方案

来源：动视网责编：小采时间：2020-11-09 11:57:12

MySQL连接数据库函数内存泄露解决方案

MySQL连接数据库函数内存泄露解决方案:Linux 下使用C操作MySQL数据库时写个测试程序 int main(void) { MYSQL m_mysql; mysql_init(m_mysql); Linux 下使用C操作MySQL数据库时写个测试程序 { MYSQL m_mysql; mysql_init(&m_mysql);

推荐度：

点击下载本文 文档为doc格式

导读MySQL连接数据库函数内存泄露解决方案:Linux 下使用C操作MySQL数据库时写个测试程序 int main(void) { MYSQL m_mysql; mysql_init(m_mysql); Linux 下使用C操作MySQL数据库时写个测试程序 { MYSQL m_mysql; mysql_init(&m_mysql);

Linux 下使用C操作MySQL数据库时写个测试程序 int main(void) { MYSQL m_mysql; mysql_init(m_mysql);

Linux 下使用C操作MySQL数据库时写个测试程序

{

MYSQL m_mysql;

mysql_init(&m_mysql);

if(mysql_real_connect(&m_mysql,pLocalhost,pUser,pPass,pDB,0,NULL,0) == NULL)

//mysql_connect() 连接一个MySQL服务器。该函数不推荐；使用mysql_real_connect()代替。

cout<<"connect failed"< else

cout<<"connect success"<

mysql_close(&m_mysql);

编译后使用valgrind检测内存泄露

[root@localhost string]# valgrind --tool=memcheck --leak-check=full ./mysql
==10352== Memcheck, a memory error detector
==10352== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==10352== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==10352== Command: ./mysql
==10352==
connect success
==10352==
==10352== HEAP SUMMARY:
==10352== in use at exit: 61,336 bytes in 16 blocks
==10352== total heap usage: 118 allocs, 102 frees, 115,929 bytes allocated
==10352==
==10352== 24,528 bytes in 6 blocks are possibly lost in loss record 4 of 5
==10352== at 0x4005903: malloc (vg_replace_malloc.c:195)
==10352== by 0x30DD75: my_once_alloc (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x30E59C: ??? (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x30EF96: ??? (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x30F111: get_charset_by_csname (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x32C3D2: mysql_init_character_set (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x32DABB: mysql_real_connect (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x8048A76: main (str.cpp:32)
==10352==
==10352== 28,616 bytes in 7 blocks are possibly lost in loss record 5 of 5
==10352== at 0x4005903: malloc (vg_replace_malloc.c:195)
==10352== by 0x30DD75: my_once_alloc (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x30E57A: ??? (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x30EF96: ??? (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x30F111: get_charset_by_csname (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x32C3D2: mysql_init_character_set (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x32DABB: mysql_real_connect (in /usr/lib/mysql/libmysqlclient.so.15.0.0)
==10352== by 0x8048A76: main (str.cpp:32)
==10352==
==10352== LEAK SUMMARY:
==10352== definitely lost: 0 bytes in 0 blocks
==10352== indirectly lost: 0 bytes in 0 blocks
==10352== possibly lost: 53,144 bytes in 13 blocks
==10352== still reachable: 8,192 bytes in 3 blocks
==10352== suppressed: 0 bytes in 0 blocks
==10352== Reachable blocks (those to which a pointer was found) are not shown.
==10352== To see them, rerun with: --leak-check=full --show-reachable=yes
==10352==
==10352== For counts of detected and suppressed errors, rerun with: -v
==10352== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 3