1

メモリ使用量とスレッド使用量モニター

私は私の大学を代表してこの投稿を投稿しています。

彼は、handle_option（MySQL getopt lib）を使用して構成ファイル（/etc/my.cnf）を読み取るときに、疑わしいメモリリークを発見しました。

彼はmallochost_name、usernameの後に以下のソースコードを実行します。

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);

彼は、上記の方法がfree（host_name）とfree（user_name）を使用する代わりにError（Segment）を使用していると述べていますか？それで、これがメモリリークを引き起こす可能性のある理由ですか？

ええと..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

handle_optionsprintf("user_name: %p; host_name: %p\n", (void *) user_name, (void *) host_name);の呼び出しの前後に配置して、コードを実行します。結果として出力される追加の 2 行は互いに異なりますか? その場合、診断は正しく、user_name と host_name は handle_options によって変更されます。おそらく、malloc されたポインターの使用はこの関数には適していません。

そうでない場合は、診断が正しくなく、メモリ リークが別の場所にあります。MS_MYSQL_init、main_proc、main のソース コードをこの順序で確認することをお勧めします。これらは、プロジェクトの valgrind によってリストされた 3 つの関数です。私の助けが必要な場合はお知らせください...

于 2013-03-22T06:39:34.827 に答える
0

ポインターへのメモリの割り当てとismy_option.valueの使用の組み合わせは、 に割り当てられたものをGET_STRリークすることにつながります。値が指しているものを解放せずに、以前に指していました。my_option.valueGET_PTRmy_option.valueargvhandle_optionsmy_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 に答える