在MySQL中使用getopt lib時可疑的內存泄漏？

Question

我代表我的大學張貼這篇文章。

當使用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)

Answer 1

把printf("user_name: %p; host_name: %p\\n", (void *) user_name, (void *) host_name); 調用handle_options之前和之后並運行您的代碼。 結果打印的另外兩行是否彼此不同？ 如果是這樣，則您的診斷是正確的，並且handle_options更改了user_name和host_name，並且可能不適合使用使用malloc指針的函數。

否則，您的診斷不正確，並且內存泄漏在其他地方。 您需要按順序查看MS_MYSQL_init，main_proc和main的源代碼，這是valgrind從您的項目中列出的三個函數。 讓我知道您是否需要我的幫助...

Answer 2

我想說分配內存指針的組合my_option.value指向與使用沿着GET_STR是導致漏水什么已分配給my_option.value ，作為GET_PTR initalises什么my_option.value指向，指向有權移至以argv傳遞到handle_options ，而無需釋放先前指向的my_option.value所指向的值。

為了解決這個問題，要么不分配任何內存什么my_option.value將其傳遞給指向之前handle_options或使用分配它my_alloc()並使用GET_PTR_ALLOC為價值型，為GET_PTR_ALLOC意味着調用my_free()什么my_option.value在重新初始化它指向之前指向。

---

出於好奇：什么是uchar ，為什么要轉換為my_option.value類型的uchar **而不是void * ？

---

還有這個

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

應該讀

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

不是嗎