在MySQL中使用getopt lib时可疑的内存泄漏？

Memory Usage and Thread Usage monitor 在MySQL中使用getopt lib时可疑的内存泄漏？

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

他发现了一个可疑的内存泄漏使用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);

他提到上面的方法是使用错误（段），而不是使用免费（主机名）和免费（用户名）？所以这是造成内存泄漏的可能原因？

嗯..我在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)

来源

2013-03-22 jhyap

将host_name和user_name更改为'uchar *'可能是一个好主意，以避免从'char **'到'uchar **'的转换不是很好定义。 – Sebivor 2013-03-22 01:38:46

您是否考虑过使用valgrind来确定哪块内存在泄漏？ – Sebivor 2013-03-22 01:47:19

Ivalue，我刚刚更新了帖子。我们运行Valgrind并检查内存泄漏。事实上，这是我们第一次使用Valgrind，所以如何从上面解释Valgrind报告？ – jhyap 2013-03-22 06:05:37

把printf("user_name: %p; host_name: %p\n", (void *) user_name, (void *) host_name);前后调用handle_options后并运行代码。作为结果打印的另外两行不同？如果是这样，你的诊断是正确的，user_name和host_name由handle_options改变，也许使用malloc'd指针不适合这个函数。

如果不是，您的诊断是不正确的，内存泄漏位于其他地方。您需要按顺序查看MS_MYSQL_init，main_proc和main的源代码，这是valgrind从您的项目中列出的三个函数。让我知道，如果你需要我的帮助......

来源

2013-03-22 06:39:34 Sebivor

我想说分配内存的指针my_option.value的组合指向与使用GET_STR一起是导致漏水什么已分配给my_option.value，为GET_PTR指出my_option.value正指向什么，指向正确的位置，指向argv至handle_options所传递的内容，而没有释放之前指向的值my_option.value指向的值。

为了解决这个问题，要么不把它传递给handle_options分配任何内存什么my_option.value指向前或使用my_alloc()分配并使用GET_PTR_ALLOC为价值型，为GET_PTR_ALLOC意味着什么my_option.value是my_free()通话指出在重新初始化它指向的内容之前。

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

而且这个

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

应该读

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

不应该吗？

来源

2013-03-22 08:25:43 alk

在MySQL中使用getopt lib时可疑的内存泄漏？

回答

相关问题