1

内存使用和线程使用监视器

我代表我的大学发布这篇文章。

他在使用 handle_option (MySQL getopt lib) 读取配置文件 (/etc/my.cnf) 时发现了可疑的内存泄漏

他在malloc host_name、用户名之后执行下面的源码：

char* host_name;
char* user_name;

struct my_option mysql_confgs[] = 
{
  {"host", "h", "MySQL Server", (uchar**) & host_name, NULL, NULL, GET_STR, 
REQUIRED_ARG, 0,0,0,0,0,0},
    {"user", "u", "userID", "h",(uchar**) & user_name, NULL, NULL, GET_STR, 
REQUIRED_ARG, 0,0,0,0,0,0}
}

handle_options(&argc, &argv, mysql_configs, aux_config_reader);

他提到上面的方法是使用Error（Segment）而不是使用free（host_name）和free（user_name）？那么这是造成内存泄漏的可能原因吗？

嗯.. 我对 MySQL 的基础知识为零，所以我可能无法提供 100% 的问题描述。因此，请随时对此进行查询，我将根据查询更新问题描述的详细信息。

我的大学有语言障碍，所以我代表他发帖。

Valgrind 报告： 

480 bytes in 1 blocks are possibly lost in loss record 26 of 43
at 0x4A068FE: malloc (vg_replace_malloc.c:270)
by 0x33E4E293C1: my_malloc (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x33E4E2C974: alloc_root (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x33E4E2E620: ??? (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x33E4E2F838: my_load_defaults (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x408BF1: MS_MYSQL_init (MS_MYSQL_O.h:109)
by 0x438A39: main_proc (AccLab.c:221)
by 0x437F8A: main (AccLab.c:67)

75,840 bytes in 158 blocks are definitely lost in loss record 41 of 43
at 0x4A068FE: malloc (vg_replace_malloc.c:270)
by 0x33E4E293C1: my_malloc (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x33E4E2C974: alloc_root (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x33E4E2E620: ??? (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x33E4E2F838: my_load_defaults (in /usr/lib64/mysql/libmysqlclient.so.16.0.0)
by 0x408BF1: MS_MYSQL_init (MS_MYSQL_O.h:109)
by 0x438A39: main_proc (AccLab.c:221)
by 0x437F8A: main (AccLab.c:67)

泄漏摘要：

definitely lost: 75,840 bytes in 158 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 2,304 bytes in 7 blocks
still reachable: 9,675,408 bytes in 2,387 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-reachable=yes

For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 4 from 4)
4

2 回答 2

0

printf("user_name: %p; host_name: %p\n", (void *) user_name, (void *) host_name);在调用 handle_options 之前和之后放置并运行您的代码。结果打印的另外两行是否彼此不同？如果是这样，您的诊断是正确的，并且 user_name 和 host_name 由 handle_options 更改，并且可能使用 malloc 的指针不适合此功能。

如果不是，则您的诊断不正确，并且内存泄漏在其他地方。您需要按顺序查看 MS_MYSQL_init、main_proc 和 main 的源代码，它们是项目中 valgrind 列出的三个函数。如果您需要我的帮助，请告诉我...

于 2013-03-22T06:39:34.827 回答
0

我会说将内存分配给指针my_option.value所指向的组合以及使用GET_STR导致泄漏已分配给的内容my_option.value，如GET_PTR初始化所my_option.value指向的内容，指向已传递的内容中的某个argv地方handle_options，没有释放值my_option.value指向的东西，以前指向的东西。

my_option.value为了解决这个问题，要么在将其传递给之前不分配任何内存到所指向的内容，要么使用并用作值类型来handle_options分配它，这意味着在重新初始化它所指向的内容之前调用所指向的内容至。my_alloc()GET_PTR_ALLOCGET_PTR_ALLOCmy_free()my_option.value

只是出于好奇：什么是uchar，为什么你投到uchar **而不是void *，类型my_option.value？

还有这个

"user", "u", "userID", "h",(uchar**) & user_name ...

应该读

"user", "u", "userID", (uchar**) & user_name ...

不应该吗？

于 2013-03-22T08:25:43.700 回答