[英]Valgrind Possibly Lost - MYSQL
I've recently been running one of my apps through Valgrind but there's a few MYSQL related leaks I can't fix. 我最近一直通过Valgrind运行我的一个应用程序,但是有一些MYSQL相关的泄漏我无法解决。 I put the offending code in the most basic form and tested that;
我把违规代码放在最基本的形式并测试了; I got the same leaks.
我得到了同样的泄漏。 Should I just disregard them or am I doing something wrong?
我应该忽视它们还是我做错了什么?
Code: 码:
#include <stdio.h>
#include <stdlib.h>
#include <mysql/mysql.h>
int main()
{
MYSQL *MYSQLIns;
MYSQLIns = mysql_init(NULL);
mysql_real_connect(MYSQLIns, "localhost", "username", "password", "database", 0, NULL, 0);
mysql_close(MYSQLIns);
return EXIT_SUCCESS;
}
Compiled With: 编译:
gcc -g -lmysqlclient mysql_mem_test.c -o mysql_mem_test
Valgrind Output: Valgrind输出:
valgrind --leak-check=full ./mysql_mem_test
==4601== Memcheck, a memory error detector
==4601== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4601== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==4601== Command: ./mysql_mem_test
==4601==
==4601==
==4601== HEAP SUMMARY:
==4601== in use at exit: 61,336 bytes in 16 blocks
==4601== total heap usage: 70 allocs, 54 frees, 109,218 bytes allocated
==4601==
==4601== 24,528 bytes in 6 blocks are possibly lost in loss record 4 of 5
==4601== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==4601== by 0x4079BB2: my_once_alloc (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x407A408: ??? (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x407AED1: ??? (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x407B112: get_charset_by_csname (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x409D55B: mysql_init_character_set (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x409F5A1: mysql_real_connect (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x80485E0: main (mysql_mem_test.c:12)
==4601==
==4601== 28,616 bytes in 7 blocks are possibly lost in loss record 5 of 5
==4601== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==4601== by 0x4079BB2: my_once_alloc (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x407A3E9: ??? (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x407AED1: ??? (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x407B112: get_charset_by_csname (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x409D55B: mysql_init_character_set (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x409F5A1: mysql_real_connect (in /usr/lib/libmysqlclient.so.16.0.0)
==4601== by 0x80485E0: main (mysql_mem_test.c:12)
==4601==
==4601== LEAK SUMMARY:
==4601== definitely lost: 0 bytes in 0 blocks
==4601== indirectly lost: 0 bytes in 0 blocks
==4601== possibly lost: 53,144 bytes in 13 blocks
==4601== still reachable: 8,192 bytes in 3 blocks
==4601== suppressed: 0 bytes in 0 blocks
==4601== Reachable blocks (those to which a pointer was found) are not shown.
==4601== To see them, rerun with: --leak-check=full --show-reachable=yes
==4601==
==4601== For counts of detected and suppressed errors, rerun with: -v
==4601== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 55 from 38)
Does adding mysql_library_end();
添加
mysql_library_end();
after the mysql_close help? 在mysql_close帮助之后?
Update: installed valgrind and tried it and indeed it does. 更新:安装valgrind并尝试了它确实它。 mysql_init() implicitly does mysql_library_init(), but mysql_close() doesn't similarly do mysql_library_end(), which the documentation implies but doesn't come straight out and say.
mysql_init()隐式地执行mysql_library_init(),但是mysql_close()没有类似地执行mysql_library_end(),文档暗示但是并没有直接说出来。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.