« ストレステストをしてみる | トップページ | 音が出るまで、のこと その1 »

2014年4月18日 (金)

メモリリークを探る

メモリリークを調べるために、まずネットワーク通信のみの最低限の動作状態にして調べます。具体的にはデスクトップの表示とサウンドの再生を無効化して通信のみ行うように修正し、メモリの使用状況を調べました。

デバッグビルドした実行モジュールでは1秒に0.1MBずつメモリ消費が増えていきます。5分ほど眺めましたが10MBほど増加しました。大体においてmalloc()とfree()、newとdeleteが適切に対応できていない場合にリークするのですが、現在のソースコードではmalloc(), free()は使っておらず、new, deleteの対応も片手で数えられるくらいしかないため、問題ないように見えます。

Windows上ではすぐによいツールが見つからなかったので、Ubuntu x64 上で解析を試みることにしました。

まず、Ubuntu x64 にソースコードを転送して、ビルドできるようにします。後々のため"-g"オプションでコンパイルされるようにMakefileのCXXFLAGSに"-g"を追加してビルドします。ビルドしたバイナリを実行し、新規に端末を立ちあげて"topコマンド"を実行し、メモリ使用量の様子を観察します。

Windows上のようにメモリ使用量は増えません。おおよそ一定のように見えます。本体のコード自体にリークはなさそうです。

次にLinux上でメモリリークの検出によく使われるvalgrindというツールを用いて確認してみました。
valgrindは"sudo apt-get install valgrind"でインストールしました。100MB以上あります…

valgrind --leak-check=yes ./qtbrynhildr >& valgrind.log

ログ・ファイル valgrind.log を調べましたが、リーク自体はなさそうです。
1つだけ指摘がありました。

"new char []"で確保したメモリを"delete"で削除しているという指摘です。
これは"delete []"で削除しなくてはなりません。とりあえずそこは"delete []"に直しました。

他に指摘はなく、特にリークしている部分は本体のソースコードにはなさそうに見えます。

もう一度Windowsへ戻り、今度はリリース用にビルドしたバイナリを実行します。やはりこちらも大体一秒に0.1MB分だけメモリ使用量が増えていきます。時々急に使用量が減ることがありますが、これは常駐しているメモリ回収のフリーソフトウェアが回収しているためだと思われます。とりあえず、Windows版のQtまわりの実装のためかも、と勝手な判断をして、とりあえずペンディングとしました…

« ストレステストをしてみる | トップページ | 音が出るまで、のこと その1 »

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: メモリリークを探る:

« ストレステストをしてみる | トップページ | 音が出るまで、のこと その1 »