在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時可疑的內存泄漏？

回答

相關問題