人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

C++についてです. valgrindで次のmessageがでましたが, このmessageを消すためにどのように修正すれば良いのか分からないので, 教えてください:

==30079== 459,184 bytes in 42 blocks are still reachable in loss record 1 of 1
==30079== at 0x4A1A397: operator new(unsigned long) (vg_replace_malloc.c:167)
==30079== by 0x4BAE0BD: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned long, int&) (in /usr/lib64/libstdc++.so.5.0.6)
==30079== by 0x4BAE199: std::__default_alloc_template<true, 0>::_S_refill(unsigned long) (in /usr/lib64/libstdc++.so.5.0.6)
==30079== by 0x4BAE4FD: std::__default_alloc_template<true, 0>::allocate(unsigned long) (in /usr/lib64/libstdc++.so.5.0.6)
==30079== by 0x411CBA: std::__simple_alloc<std::_List_node<mono>, std::__default_alloc_template<true, 0> >::allocate(unsigned long) (stl_alloc.h:232)
==30079== by 0x411C8D: std::_List_alloc_base<mono, std::allocator<mono>, true>::_M_get_node() (stl_list.h:275)
==30079== by 0x411C3C: std::_List_base<mono, std::allocator<mono> >::_List_base(std::allocator<mono> const&) (stl_list.h:304)
==30079== by 0x411C0E: std::list<mono, std::allocator<mono> >::list(std::allocator<mono> const&) (stl_list.h:452)
==30079== by 0x40D6C8: poly::poly() (polynomials.h:91)


定義しているclassについて説明すると,
class mono{
...
};
class poly{
list<mono> t;
...
}
となっています.

●質問者: Q-tarou
●カテゴリ:コンピュータ
✍キーワード:AT BLOCKS C++ Class const
○ 状態 :終了
└ 回答数 : 3/3件

▽最新の回答へ

1 ● しおり
●27ポイント

これは、std::list のコンストラクタから呼ばれた

std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned long, int&) (in /usr/lib64/libstdc++.so.5.0.6)

内の new で確保したメモリーが解放されていないというメッセージですよね。

メッセージがこれだけなら libstdc++ のバグだと思います。

(std::list を使った最小限のプログラムで確認すれば判断できると思います。)


メッセージがこれだけではないのなら、new で確保した poly のオブジェクトを delete していないというようなメッセージは出力されていませんか?


C(++)言語: valgrindの使い方 (memcheck)

GCC, the GNU Compiler Collection - GNU Project - Free Software Foundation (FSF)

GCC Bugzilla Main Page

◎質問者からの返答

返信ありがとうございます. messageはコレだけです.

listを用いた簡単なprogramでも同じmessageが出るのを確認しました. ということは, listを使わない方が良いということでしょうか? それともlibstdc++を書き換えるorそれにかわるものがあるのでしょうか?

本当にありがとうございます.


2 ● KYODA
●27ポイント

直感で、書いてます。

”42 blocks”とあるので、list<mono>であるtに、

42個のmonoオブジェクトが残ってしまっているのでは?

と、想像しました。

polyのデストラクタの中で、list<mono>のtを、

clear()してやったら、どうでしょうかね?

とか、思ったり。

◎質問者からの返答

返信ありがとうございます.

しかしながら, ~poly(){t.clear()};としてこのmessageが出ているので, clear()では消せてないようです.

どうして, clear()できないのかわかりません. 一応, Bookmarkerさんの回答が理由なのかなと思っていますが, webでは, bugであるかどうかみつけられず, すこし困惑しています.


3 ● しおり
●26ポイント

# OS やコンパイラーの名前とバージョン及び valgrind のバージョン等が書かれていないし、バグも突き止めていないので、推測/憶測で書きますが…

libstdc++ のバージョンから推測すると、コンパイラーは g++ (GCC) 3.3.4 辺りをお使いだと思いますが、可能なら 3.4.6 にバージョンアップしてみてください。

少なくとも下記環境では、ご質問のようなメモリーリークは検出されませんでした。

OS
FreeBSD 6.2-RELEASE
コンパイラー
g++ (GCC) 3.4.6
検査ツール
valgrind-stable-352(Valgrind was ported to FreeBSD by Doug Rabson (http://www.rabson.org/))

なお、3.3 系列の最新リリース版である 3.3.6 でも同様のメモリーリークが検出されます。


テストプログラム

#include <list>

int main()
{
 std::list<int> obj;
}

# これで駄目なら私は回答権がなくなりますので回答できませんm(__)m

◎質問者からの返答

回答ありがとうございます.

OS はSuSe Linuxでkernelのversionが2.6.5-7.139-smpです, g++のversionは3.3.3で, valgrindのversionが3.2.3です

こちらでも, 上記の環境でg++ 4.0.1を利用して確認したところ, valgrindがメモリーリークを報告しませんでした.

後ほど, 3.4.6で試してみたいと思います. 有用な情報を教えていただき, ありがとうございました.

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ