2

私は次のコード構造を持っています (コード全体が巨大で、このスニペットは私の問題に関連していると思います)、

MYSQL_RES *res_set;
MYSQL_ROW row;
MYSQL *connect;

int main()
{
 connect=mysql_init(NULL);
 mysql_real_connect(connect, NULL, "root", "suvp" ,"Employees" ,0,NULL,0);

 /*Other Code*/

 mysql_free_result(res_set);
 mysql_close(connect);
}

データベース接続の変数はグローバルです。私の「その他のコード」では、必要に応じて初期化connectされた (in mysql_queryetc で) and rowand andを使用する他の関数を呼び出しますres_set。ご覧のとおり、結果を解放し、メインの最後で接続を閉じます。

res_setある関数から別の関数に (毎回解放せずに) 再利用します。それは問題を引き起こしますか？

私が使用するすべての機能で、ステートメントは似ています

mysql_query(connect,myQuery.c_str())
res_set = mysql_store_result(connect);
row = mysql_fetch_row(res_set);

Valgrind はこれを報告しています。

==4864== LEAK SUMMARY:
==4864==    definitely lost: 0 bytes in 0 blocks
==4864==    indirectly lost: 0 bytes in 0 blocks
==4864==      possibly lost: 0 bytes in 0 blocks
==4864==    still reachable: 99,954 bytes in 30 blocks
==4864==         suppressed: 0 bytes in 0 blocks

詳細なエラーは、

mysql_real_connect

メイン関数から呼び出されます。

このページによると、呼び出しmysql_library_end()は良い習慣です。しかしmysql_library_end()、接続を閉じた後に電話をかけた後でも。ヴァルグリンド曰く、

==5120== HEAP SUMMARY:
==5120==     in use at exit: 116,466 bytes in 34 blocks
==5120==   total heap usage: 95 allocs, 61 frees, 147,218 bytes allocated

==5120== LEAK SUMMARY:
==5120==    definitely lost: 0 bytes in 0 blocks
==5120==    indirectly lost: 0 bytes in 0 blocks
==5120==      possibly lost: 0 bytes in 0 blocks
==5120==    still reachable: 116,466 bytes in 34 blocks
==5120==         suppressed: 0 bytes in 0 blocks

前述のように、それらはすべて要約すると次のようになります。mysql_real_connect

プログラムは正常に実行されます。しかし、valgrind によって示される問題があります。どこが間違っていますか？

4

1 に答える 1

2

おそらく何もない。あなたはこれを読まなければなりません。最初の答えは非常に明確です。

TL;DR: まだ到達可能であるのは、実際の「メモリ リーク」ではなく、プログラムが終了しようとしているときに、プログラム内にそのメモリへのポインタがまだ存在していたメモリです (プログラム内のポインタは、プログラムが終了する前に解放されませんでした)。

Valgrind によって検出されたまだ到達可能なリーク

于 2013-05-28T10:55:02.073 に答える