松尾です。 書いていたらすごく長くなってしまいました。 要点はつぎの2点です。 - free()するようにしよう - ttpset.dll は ttermpro.exe に統合してたほうが安全 On 2022/05/19 23:10, NAGATA Shinya wrote: > - VTWin::OnClose で VT ウィンドウのアイコンを Destroy していない > - NotifyCreate() で malloc した NotifyIcon が NotifyDelete() で > free されていない > > このへんは Windows に任せておいてよいでしょうか。 すべてdestroy(),free()したい、 でも大変だったらそのままでもいいか、Windowsに任せよう、 という感じでいました。 これに関連して、 TTSetIcon()で、アイコン名にNULLを渡した時の動作ですが、 (r9933で直していただいたtypoのところです) もしかすると、NULL を WM_SETICONして、 戻ってきたハンドルをDestroyIcon() するほうが 良いような気もします。考え中です。 ttermpro.exe を DebugビルドしてVS上で動かすと、 プログラム終了時に開放していないメモリがあるとダンプされると思います。 これを眺めていて自分の想定している部分が出ているとそのうち直そうと思い、 想定外のダンプやファイル名と行番号がないダンプが出ていると調べるようにしています。 libressl内でfree()していないメモリがあるようだな、とか。 最近だとr9923の修正は想定外のダンプを見つけたのがきっかけでした。 プログラム動作中に1回確保してプログラム終了までずっと使って 終了時にfree()しないというのは、 そういうのもあってもいいじゃないかというのが私の考えでです。 開放しない=メモリリーク=絶対あかん、とは思わないです。 でも全部free()するのがきれいですよね。 何か処理するごとにメモリを確保して、 もう使わないのに解放せず、次々とメモリを確保していくのは、 よくないメモリリークで、何とかしないといけないと思います。 ダンプ見みて、free()していないのは意図通りなのかわからないので なるべくすべて free() するのが良いと思います。 今後はダンプが出ない状態を目指してすすめましょうか (free()しないないならソースにかいておく、ですね) 現在、ダンプされるなかで、確保元ファイル名が win32helper.cpp、asprintf.cpp で、 メモリの内容がパスっぽいものは、想定内というか、 free()をどうするか考えるのを後回しにしていたものです。 iniファイルを読み込むttpset.dllでファイル名などを 動的なメモリ(=ヒープ)に確保しています。 このヒープはttpset.dllのものなのでの、 他のモジュール(dll,exe)で操作(free()など)を行うのは良くないとされています。 でもうまく動く場合も多々あるようで、よくわからないところです。 r9442の「ウィンドウの設定ダイアログにフレームを表示しない設定を追加」の動作を Windows XPで様子を見ようとしたのですが、 TERATERM.INIを保存しようとすると、 ttpset.dllで確保したメモリ(パス)をttermpro.exeでfree()しようとして 例外で落ちるようでした。 ttpset.dllのヒープをttermpro.exeで操作しようとしたことになります。 私が開発に使っているWindows 10ではokで、 試したXPでだめな理由はよくわかっていないのですが、 ttpset.dllはttermpro.exeにマージするのが安全ではないかと思っています。 特に困ることがなければマージを考えようと思います。 何か問題ありそうでしょうか?
Tera Term