プログラムのデバッグ
A,kira Ishikawa
現在、ＭＳＤＯＳ互換ＯＳを使ってデータ収集装置を作っています。
開発環境：ＢｏｒｌａｎｄＣ＋＋５．０２
作ったプログラムを実行すると、いつも同じではありませんが
１時間から１０時間程度で暴走してしまいます。
予想では、メモリリークなどが発生している為だと思っています。
Ｗｉｎｄｏｗｓ用のアプリケーションを作る場合、このような問題を
比較的簡単に見つけれるツールがありますが、
ＤＯＳの場合はどのようにすれば宜しいでしょうか？。
お手数ですが、アドバイスや、ツールの紹介をお願いします。
宜しくお願いします。
Shinji KONO
In article <3DCA298A...@keisoku.toyotamacs.co.jp>, "A,kira Ishikawa" <ak...@keisoku.toyotamacs.co.jp> writes
>開発環境：ＢｏｒｌａｎｄＣ＋＋５．０２
...
>予想では、メモリリークなどが発生している為だと思っています。
>Ｗｉｎｄｏｗｓ用のアプリケーションを作る場合、このような問題を
>比較的簡単に見つけれるツールがありますが、
Boraland C++ に、そういう機能があったと思います。
Effective C++ かなんかを読んだ方が根本的な解決になるかも知れ
ませんね。C++ は本質的にメモリリークしやすい言語なので。
どういうプログラムしているかにもよるとは思うんだけど。
new なんかしねぇ、malloc/free だけだとかいうなら、まぁ、
malloc のデバッグオプションでしょう。
いずれにせよ数十時間動くようなプログラムだとメモリの使用状況
を調べるものは書かざるを得ないだろうなぁ。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
A,kira Ishikawa
河野殿、ご返答、有難うございます。
>>開発環境：ＢｏｒｌａｎｄＣ＋＋５．０２
>>予想では、メモリリークなどが発生している為だと思っています。
>>Ｗｉｎｄｏｗｓ用のアプリケーションを作る場合、このような問題を
>>比較的簡単に見つけれるツールがありますが、
>
> Boraland C++ に、そういう機能があったと思います。
調べてみます。
> どういうプログラムしているかにもよるとは思うんだけど。
> new なんかしねぇ、malloc/free だけだとかいうなら、まぁ、
> malloc のデバッグオプションでしょう。
malloc/freeは使わず、new/deleteを使っています。
> いずれにせよ数十時間動くようなプログラムだとメモリの使用状況
> を調べるものは書かざるを得ないだろうなぁ。
この調べるものを作る場合、
new/deleteをラッピングして、
領域を確保した時のサイズを加算する。
領域を開放した時のサイズを減算する。
というような関数／クラスを作り、
メモリリークの検査を行うという流れになるんでしょうか？。
お手数ですが、経験が少ないので
ご助言していただけると助かります。
Shinji KONO
In article <3DCB0272...@keisoku.toyotamacs.co.jp>, "A,kira Ishikawa" <ak...@keisoku.toyotamacs.co.jp> writes
>new/deleteをラッピングして、
>領域を確保した時のサイズを加算する。
>領域を開放した時のサイズを減算する。
>というような関数／クラスを作り、
>メモリリークの検査を行うという流れになるんでしょうか？。
allocator を自分で作れと Effective C++ は言っているようです。
必要なら reference count / garbage collect でしょう。
Effective C++ は必須です。是非読みましょう。
ラッピングってオブジェクト指向っぽくない言い方。別にどうって
ことないけど。
A,kira Ishikawa
河野殿、ご返答、有難うございます。
>>new/deleteをラッピングして、
>>領域を確保した時のサイズを加算する。
>>領域を開放した時のサイズを減算する。
>>というような関数／クラスを作り、
>>メモリリークの検査を行うという流れになるんでしょうか？。
>
> allocator を自分で作れと Effective C++ は言っているようです。
> 必要なら reference count / garbage collect でしょう。
> Effective C++ は必須です。是非読みましょう。
はい。今日、本屋に行ってきます。
> ラッピングってオブジェクト指向っぽくない言い方。別にどうって
> ことないけど。
えっと、オブジェクト指向的に言うと派生になるんでしょうか？。
Ｃ言語の経験が長く、Ｃ＋＋は始めたばかりで、
今書いているプログラムもＣ言語で書いたようになっています。
自分で書いたプログラムを見ると、自分でも情けない気分になります。
とりあえず、お教え頂いた方法を使ってみます。
結果が出ましたら報告します。
有難うございました。
Yasushi Kondo
"Shinji KONO" <ko...@ie.u-ryukyu.ac.jp> wrote in message
news:28842.10...@insigna.ie.u-ryukyu.ac.jp...
| 河野 真治@琉球大情報工学です。
|
| In article <3DCA298A...@keisoku.toyotamacs.co.jp>, "A,kira Ishikawa"
<ak...@keisoku.toyotamacs.co.jp> writes
| >開発環境：ＢｏｒｌａｎｄＣ＋＋５．０２
| ...
| >予想では、メモリリークなどが発生している為だと思っています。
| >Ｗｉｎｄｏｗｓ用のアプリケーションを作る場合、このような問題を
| >比較的簡単に見つけれるツールがありますが、
|
| Boraland C++ に、そういう機能があったと思います。
|
| Effective C++ かなんかを読んだ方が根本的な解決になるかも知れ
| ませんね。C++ は本質的にメモリリークしやすい言語なので。
|
| どういうプログラムしているかにもよるとは思うんだけど。
| new なんかしねぇ、malloc/free だけだとかいうなら、まぁ、
| malloc のデバッグオプションでしょう。
|
| いずれにせよ数十時間動くようなプログラムだとメモリの使用状況
| を調べるものは書かざるを得ないだろうなぁ。
単純に、メモリの断片化が起こっているだけかも？
１６ビットＤＯＳエクステンダーで遊んだのですが、、、
縞模様の様にメモリを取得して、縞模様の１つの色？の部分を開放すると、一見多
くメモリが存在する様に見えますが、大きなメモリエリアを取得しようとすると失敗
します。
ＯＳ／２（１６ビット版）は、Config.sysでメモリのコンパクションのするしない
の設定が出来ましたね。
あと、XPaintのソースを解析したときは、アプリが自前でメモリ管理を行っていま
した。
連続稼動を考えるアプリは、ＯＳとのメモリ取得開放動作は、起動時と終了時の
みって割り切った方が安全です。
Akira Ishikawa
近藤殿、ご返答、ありがとうございます。
> | いずれにせよ数十時間動くようなプログラムだとメモリの使用状況
> | を調べるものは書かざるを得ないだろうなぁ。
>
> 単純に、メモリの断片化が起こっているだけかも？
> １６ビットＤＯＳエクステンダーで遊んだのですが、、、
> 縞模様の様にメモリを取得して、縞模様の１つの色？の部分を開放すると、一見多
> くメモリが存在する様に見えますが、大きなメモリエリアを取得しようとすると失敗
> します。
> ＯＳ／２（１６ビット版）は、Config.sysでメモリのコンパクションのするしない
> の設定が出来ましたね。
>
> あと、XPaintのソースを解析したときは、アプリが自前でメモリ管理を行っていま
> した。
>
> 連続稼動を考えるアプリは、ＯＳとのメモリ取得開放動作は、起動時と終了時の
> みって割り切った方が安全です。
ご助言を踏まえて処理を追加してみます。