[ 新規に投稿する ]
「BeginMacro Memory Error」が発声するNo.07566
陸 さん　21/01/20 08:38　[ コメントを投稿する ]
　 　お世話になっております。

　秀丸メール 6.98β2をインストールしてしばらく利用しているのですが、「BeginMacro Memory Error」というようなエラーが発声するようになってしまいました。
　ちなみに、そこでEnterキーを押すと、

VirtualAlloc error. Maybe terminate abnormal. code=8 size=4194304

というようなエラーが発生して、秀丸メールが保護違反で落ちてしまいました。
　何か対処法はありますでしょうか。
　環境は、Windows10 20H2 64ビット、秀丸メール 6.98β2です。

　以上、よろしくお願いいたします。
[ △ ]
RE:07566 「BeginMacro Memory Error」が発声するNo.07568
秀まるお2 さん　21/01/20 08:54　[ コメントを投稿する ]
　 　そのエラーはマクロ実行の時にメモリを確保しようとしてWindowsからエラーが返ってるようです。

　マクロ関係の処理というか、そもそも的に秀丸エディタ相当部分についてははVersion 6.97から何もいじってないので、その辺がおかしいことは無いはずだと思います。秀丸メールの方で何かいじった所のせいでメモリを壊してるのかもしれません。

　最近の修正箇所などを見直してみます。
[ △ ]
RE:07568 「BeginMacro Memory Error」が発声するNo.07569
陸 さん　21/01/20 09:03　[ コメントを投稿する ]
　 　お世話になります。

>　最近の修正箇所などを見直してみます。

　ありがとうございます。
　こちらでももう少し状況を見てみようと思います。
　ちなみに、保護違反が発生した際に、「dump.txt」が出力されていたので、必要でしたらお送りします。
　昨日の夜あたりからログをとってみているので、少しファイルサイズが大きくなってしまっていますが…。

　それでは。
[ △ ]
RE:07569 「BeginMacro Memory Error」が発声するNo.07570
秀まるお2 さん　21/01/20 10:24　[ コメントを投稿する ]
　 　お手数かけてすみません。

　調べてみた結果を２点連絡させていただきます。

■調査結果１：メモリ不足が起きてる？

　まず、エラーの現象として、どうもメモリ不足が起きてるようでした。

　まず、「BeginMacro Memory Error」のエラーが出る原因は、何かのマクロを実行しようとした時に、マクロ変数用のメモリとして３メガバイトのメモリを確保しようとして、VirtualAllocっていうAPI呼び出しをして、それでエラーになってるようです。

　このエラーが出ても保護違反で落ちることはなく、しかもマクロも実行されます。ただし、マクロの中で何らかの変数を使うと、そのタイミングで「マクロエラー：文字列が長すぎます。」みたいなエラーが出てマクロが止まるようではあります。

　それが出る/出ないは別として、その後「VirtualAlloc error.」のエラーが出るということで、そっちのエラーは秀丸メールの中の処理でVirtualAllocで同じくエラーが発生してて、エラーコードが8ということは、つまり「ERROR_NOT_ENOUGH_MEMORY」のエラーが出てることになります。ちなみに確保しようとしたメモリサイズは４メガバイトになってます。

　ということは、何らかの理由でメモリ不足というか、実際には物理メモリの不足ではなくてアドレス空間の不足が発生してるのかなぁと思いつつも、64bit版でそんなことは普通起こらないです。たとえば意図的にメモリリークを発生させたとしても、メモリ不足のエラーが出るまでには大変な時間（何日も）かかると思うし、その前にマシンが極端に重くなると思います。

　ということで、ちょっとこの辺の発生理由が分かりません。

■調査結果２：ソースコードの修正箇所

　Version 6.98β1、β2での修正箇所を調べてみたんですが、一応今回の問題と関係しそうな修正は無いようでした。

　β1での修正は本当にささいな修正だけだし、β2での修正は、フォルダ名を変更した時の処理だけです。フォルダ名変更をしてなければ関係無いです。

　ってことで、少なくともV6.98β1、V6.98β2での修正が関係してることは無さそうな気がします。

--------------------------------------------------
　ってことでよく分からなくなりました。

　一回Windows10を再起動したら直ったりしないでしょうか。

　dump.txtは、送っていただいてもそれで解決できる可能性は低い気がするのですが、他に原因を調べるネタが無いので、もし可能でしたら送ってほしいです。宛先は"maruo@mitene.or.jp"になります。
[ △ ]
RE:07570 「BeginMacro Memory Error」が発声するNo.07571
秀まるお2 さん　21/01/20 10:35　[ コメントを投稿する ]
　 　追加ですみません。

　Windows10を再起動してもダメでしたら、念のためVersion 6.97に戻して様子見していただく手もあります。それで起きないなら、たしかに最近のβ版での修正箇所が関係してることになると思います。
[ △ ]
RE:07570 「BeginMacro Memory Error」が発声するNo.07572
陸 さん　21/01/20 10:40　[ コメントを投稿する ]
　 　お世話になっております。

　調べていただき、ありがとうございます。

>　このエラーが出ても保護違反で落ちることはなく、しかもマクロも実行されます。ただし、マクロの中で何らかの変数を使うと、そのタイミングで「マクロエラー：文字列が長すぎます。」みたいなエラーが出てマクロが止まるようではあります。

　確かに、そのエラーが出たこともありました。
　ただ、出るときと出ないときがあるようです。
　ちなみに、下記のようなマクロを自動起動の「受信が一段落したとき」に登録しているのですが、どうもその際にエラーが起きているような感じです。

----- マクロ内容 -----
loaddll "tkinfo.dll";
#count = dllfunc("RecvMailCountShow");
if( #count == 0 ) {
endmacro;
}
$list = "";
#i = 0;
while( #i < #count ) {
$account = dllfuncstr("GetLastRecvMailAccount", #i);
if( $account == "" ) {
break;
}
$account = $account + "\r\n";
if( $account == $accountPrev ) {
//直前のと同じ
} else {
#x = strstr( $list, $account );
if( #x >= 0
&& (#x == 0 || midstr($list, #x-1, 1) == "\n") ) {
//既に追加してある
} else {
$list = $list + $account;
}
$accountPrev = $account;
}
#i = #i + 1;
}
$message = $list + str(#count) + "通のメールを受信しました。";
//#n = dllfunc("HideNotifyWnd");
#n = dllfunc("ShowBalloonMessage", "", $message, 1);
//#n = dllfunc("ShowNotifyWnd", "", $message);
endmacro;
--------------------

　それから、追加ですみませんが、保護違反が発生して秀丸メールが終了したあと、再度秀丸メールを立ち上げると、下記のような内容が表示されました。

InternetGetConnectedState関数呼び出しで異常が発生しました。「全般的な設定・ダイヤルアップ接続」の「LAN接続」をONにして、さらに「全般的な設定・定期受信」の「ネットワークが有効な時のみ」もOFFにすれば回避出来ると思います。

　とりあえず、現在はβ1に戻して、しばらく運用しています。
　また、パソコンの再起動も行ってみましたが、変化ないようでした。

　「dump.txt」は別途メール送付させていただきました。

　以上、よろしくお願いいたします。
[ △ ]
RE:07572 「BeginMacro Memory Error」が発声するNo.07574
秀まるお2 さん　21/01/20 11:06　[ コメントを投稿する ]
　 　お手数かけてすません。送っていただいたdump.txtにメモリ使用量の記録がありまして、それで１つ分かりました。

　秀丸メールが64bit版かと勘違いしました。実際は32bit版でした。

　dump.txtの中に「AvailVirtual=」の記録があって、その値は空き仮想メモリの量でキロバイト単位の値なんですが、43メガバイトまで減ってるようで、実際にメモリ不足が起きてるようです。

　なぜメモリ不足になるのかって方向で調べてみます。
[ △ ]
RE:07574 「BeginMacro Memory Error」が発声するNo.07577
秀まるお2 さん　21/01/20 15:00　[ コメントを投稿する ]
　 　陸さんの所に限ってメモリ不足が起きるということは、音声化の関係なんじゃないかと思って、その辺調べてみたら、マクロの「ddeinitiate」でメモリリークというか、メモリを確保しつつ、解放し忘れてる処理が見つかってしまいました。

　今そこを直して、Version 6.98β3としてアップロードしました。すみませんがこれに入れ替えて様子見お願いしたいです。

32bit版:
https://hide.maruo.co.jp/software/bin3/hmmail698b3_signed.exe

音声化版:
https://hide.maruo.co.jp/software/bin3/hmmail698b3speech_signed.exe

64bit版:
https://hide.maruo.co.jp/software/bin3/hmmail698b3_x64_signed.exe

　秀丸エディタのVersion 8.56からメモリリークしてるみたいなので、だいぶ前からバグってたのが、たまたま今のタイミングでメモリ不足が起きたということじゃないかと思います。

　秀丸メールのメモリ使用量は、タスクマネージャから確認が出来ます。メモリ使用量が極端に増えてる場合はメモリリークがまだある可能性があります。

　すみませんがお願いします。
[ △ ]
RE:07577 「BeginMacro Memory Error」が発声するNo.07580
陸 さん　21/01/21 07:48　[ コメントを投稿する ]
　 　お世話になります。

　結論から書くと、β3をインストールしても変化ないようでした。
　また、6.97でもごくたまに起きるようでした。

>　秀丸エディタのVersion 8.56からメモリリークしてるみたいなので、だいぶ前からバグってたのが、たまたま今のタイミングでメモリ不足が起きたということじゃないかと思います。

　もしかして、これって秀丸エディタも更新しないと完全には解決しないのでしょうか。
　現在、秀丸エディタは最新の8.95を利用しているのですが。

　以上、よろしくお願いいたします。
[ △ ]
RE:07580 「BeginMacro Memory Error」が発声するNo.07582
秀まるお2 さん　21/01/21 08:39　[ コメントを投稿する ]
　 　β3でも起きるということで、お手数かけてすみません。

　一応、メモリリークのバグがあったことは間違いないはずなんですが、他の所でもメモリリークが起きてるのか、それともメモリリークとは別の問題なのか、その辺ちょっと分からずで・・・

　タスクマネージャでメモリ使用量の様子を見ていただけるとありがたいのですけど、たとえば受信コマンドを実行する度に何百メガバイトメモリ使用量が増えるとか、普通に音声化させてるだけでもメモリ使用量が増えるとか、何をしたらメモリリークするのかちょっと調べて欲しい所ではあります。

　もしかしたら陸さんの利用されてる音声化マクロでないと起きない問題かもしれないです。

　とりあえず秀丸メールの方でなんとかするとしたら、一番メモリを食うのは受信のタイミングでってことになると思うので、受信開始のタイミングで空きメモリ利用（AvailVirtualの量）を確認して、もし少なくなってる場合は再起動してから受信開始するような、そういう機能追加をしてみようかと思います。とりあえずそれで落ちなくはなると思うので。
[ △ ]
RE:07582 「BeginMacro Memory Error」が発声するNo.07583
秀まるお2 さん　21/01/21 09:14　[ コメントを投稿する ]
　 　メモリ使用量を確認する方法として、タスクマネージャを使う方法とは別に、秀丸メール上またはdump.txtのログで確認する方法がありました。（自分でも忘れてた）

　まず、マクロで、

    #n = sendmessage( hidemaruhandle(0), 0x111, 40400, 0);

　って1行のマクロを作って実行すると、

    MEM:nn TotalPhys=xxxx TotalPage=xxxx  ....  AvailVirtual=xxxx

　みたいなメッセージが出ます。そこの「AvailVirtual=」にて、秀丸メールのプロセス内の残りの仮想メモリ量が確認できます。たとえば僕の所だと、秀丸メール起動直後は1800000くらいの値なので、おおよそ1.8ギガバイトの仮想メモリが残ってることになります。

　もう１つ、dump.txtのログを取る設定にした上で、「全般的な設定・上級者向け・デバッグ」の「デバッグレベル」を1にしていただくと、dump.txtの中に、10分毎に、

18:28:32.049 (9642) MEM:44 TotalPhys=8346328 TotalPage=9657048 AvailPhys=4634700 AvailPage=6113708 TotalVirtual=4294967168 AvailVirtual=4290359640

　みたいな記録が出ます。

　それでメモリ空き容量が確認できます。

　これで見ていただく作戦でどうでしょうか。

---------------------------
　次のβ版にて、デバッグレベルを1にしてる時はステータスバーにもメモリ空き量を表示するようにしてみようと思います。
[ △ ]
RE:07582 「BeginMacro Memory Error」が発声するNo.07584
陸 さん　21/01/21 09:24　[ コメントを投稿する ]
　 　お世話になります。

　ちょっとまだデータが不十分かもしれないですが、下記のようなマクロを実行すると、メモリが少し増えるようです。
　タスクマネージャーで見ていると、メモリ使用量が30MB程度だったのが、52MB程度に増えてしまっています。
　この使用量は検索画面を閉じても減らないようです。
　ただ、2回目以降実行しても、特にメモリが増えることはないようです。
　これは、正常でしょうか。
　以下、マクロです。

----- マクロ内容 -----
//未読メールを探すマクロ
loaddll "TKInfo.dll";
#n = dllfunc("AutoRestoreFindPack");
#n = dllfunc( "SetFindPack", "flag=unread" );
#n = dllfunc("DoGrep", "", "受信+送信済み+ユーザー");
freedll;
endmacro;
--------------------

　以上、よろしくお願いいたします。
[ △ ]
RE:07584 「BeginMacro Memory Error」が発声するNo.07585
秀まるお2 さん　21/01/21 09:52　[ コメントを投稿する ]
　 　２回、3回と連続実行してメモリ使用量がほとんど変わらないようでしたら問題無いです。

　秀丸メールもそうですが、Windowsのいろんな内部の構造として、高速化のために、一度生成した物は破棄せずにそのまま次回の再利用に備える、みたいなことが多いので、１回目はメモリを食う（ウィンドウを閉じても増えたまま）になるけども、２回目以降はほとんど増えない、というこ作りになってることが多いです。

　それと、先ほどの発言でステータスバーにメモリ量表示すると書きましたが、陸さんの所は音声化で利用されてる（ステータスバーは見えない）と思うので、やっぱりこのネタはやめときます。

> メモリ使用量が30MB程度だったのが、52MB程度に増えてしまっています

　２２メガバイト増えるのが１回きりでしたら問題無いです。

　何かの操作を繰り返して、メモリ使用量が１０００メガバイトを超える、くらいのことでないといけないです。１００メガとか２００メガとかではまったくメモリ不足にはならないです。

　すみませんが、とりあえずdump.txtのログ取りをONにしてしばらく使っていただいて、もし時間があったら何か特定の操作を繰り返し実行してメモリ使用量がどんどん減る物が無いかチェックお願いしたいです。
[ △ ]
RE:07580 「BeginMacro Memory Error」が発声するNo.07587
秀まるお2 さん　21/01/21 10:38　[ コメントを投稿する ]
　 　すみません。１つお返事忘れてました。

> 　もしかして、これって秀丸エディタも更新しないと完全には解決しないのでしょうか。
> 　現在、秀丸エディタは最新の8.95を利用しているのですが。

　秀丸エディタは今回の問題には関係しないです。
[ △ ]
RE:07585 「BeginMacro Memory Error」が発声するNo.07588
陸 さん　21/01/21 11:13　[ コメントを投稿する ]
　 　お世話になります。

>　２回、3回と連続実行してメモリ使用量がほとんど変わらないようでしたら問題無いです。

　了解しました。
　しばらく様子を見てみようと思います。

>　それと、先ほどの発言でステータスバーにメモリ量表示すると書きましたが、陸さんの所は音声化で利用されてる（ステータスバーは見えない）と思うので、やっぱりこのネタはやめときます。

　tkinfo.dllをロードして、マクロで「GetStatusBarText」っていうのを実行して、ステータスバーの内容を読み上げさせたり表示させたりできるので、そこは問題ないです。
　音声化ソフトにもステータスバーを読み上げるコマンドが一応あるにはあるので。

　それでは。
[ △ ]
RE:07588 「BeginMacro Memory Error」が発声するNo.07590
陸 さん　21/01/21 11:57　[ コメントを投稿する ]
　 　お世話になります。

　いただいたメモリ容量の確認マクロを使いつつ、ときどき様子を見ていたのですが、定期受信や「すべて受信」コマンドを実行するたびに、「AvailVirtual」の値が3万ずつくらい減っているようです。
　受信終了後、しばらく時間をおいてから調べてみたりもしましたが、1万程度は増えるものの、それ以上は増えないようで、受信のたびに減ってしまっているようです。
　受信の間隔が短いもしくはアカウント数が15個程度と少し多いのが原因でしょうか。

　それでは。
[ △ ]
RE:07588 「BeginMacro Memory Error」が発声するNo.07591
秀まるお2 さん　21/01/21 12:01　[ コメントを投稿する ]
　 　しばらく使っていただいてdump.txtの中から「MEM:」でgrep検索して、どこかで極端にメモリ使用量（AvailVirtual）が増えてるとか、あるいは特定の所じゃなくて全体的にだらだらと増えているとかの傾向を見ていただいて、もしも何か特定の箇所で極端に増えてる所があれば、その増えた間でどういう操作があるかで原因特定できるかなぁかと思います。

　とりあえず僕の方で、受信系コマンドの直前にメモリの空きをチェックしてメッセージ表示＆再起動できるようにしてみます。
[ △ ]
RE:07590 「BeginMacro Memory Error」が発声するNo.07592
秀まるお2 さん　21/01/21 12:20　[ コメントを投稿する ]
　 　情報ありがとうございます。「すべて受信」を実行する度に３万キロバイト（=３０メガバイト）くらいメモリ消費が増えるということで・・・

　特に新着メールが無くても３０メガバイト増えていくってことですよね。もしかして新着メールがある時だけメモリ使用量が増えるなら、メールを解析する処理でメモリリークしてることになりますけども。

　僕の所では、「すべて送受信」を実行すると（新着メールが無いと）、最初何回かはメモリ使用量が増えていきますが、最終的にはトータル114メガバイトくらいで落ち着いてそれ以上は増えないようでした。

　すみませんが、追加テストお願いしたいです。

　１．受信後に自動起動してるマクロがあれば、それを外してどうかテストしてみて欲しい。

　２．１つ１つのアカウント単位で「受信」コマンドを実行して、どのアカウント
　　　でも同じようにメモリ消費していくのかどうか試してみて欲しい。もしかし
　　　たら特定アカウントのメールを受信しようとした時にだけメモリリークしてる
　　　かもしれない。

　ってことでどうでしょうか。
[ △ ]
RE:07592 「BeginMacro Memory Error」が発声するNo.07593
陸 さん　21/01/21 12:44　[ コメントを投稿する ]
　 　お世話になります。

>　特に新着メールが無くても３０メガバイト増えていくってことですよね。

　そうですね、新着メールはありませんでした。

　1つ1つのアカウント単位で実行してみたところ、Gmailのアカウントだけメモリ消費が激しいようです。
　ただ、このアカウントは2万5000通くらいの大量のメールがあるので、しょうがないといえばしょうがないのかもしれません。

　それでは。
[ △ ]
RE:07593 「BeginMacro Memory Error」が発声するNo.07595
秀まるお2 さん　21/01/21 14:26　[ コメントを投稿する ]
　 　僕のgmailアカウントで「すべてのメール」のフォルダも含めてIMAP4で受信する設定にしてみたんですが、「すべてのメール」配下のメールが１万８千通くらいあって、受信するのに２０分くらいかかりつつも、その後受信コマンドを繰り返しても、メモリ使用量は増えることなく安定するようでした。

　受信コマンドを実行してる最中にタスクマネージャで見ていると、メール一覧の取得が終わったくらいのタイミングでおおよそ５メガバイトくらいメモリ消費量が増えますが、受信が終わると元に戻るようでした。

　１万８千通でも５メガバイト程度なので、２万５千通あったとしても３０メガもメモリ消費量が（一時的にしろ）増えることは無さそうな気もします。

　困りました。

　送受信のやりとり記録にメモリ消費量を徹底的に出力して、果たしてどのタイミングでメモリを消費してるのかログで分かるようにする作戦を考えてみます。
　（またログ取りお願いしないといけないですが）
[ △ ]
RE:07595 「BeginMacro Memory Error」が発声するNo.07596
陸 さん　21/01/21 14:47　[ コメントを投稿する ]
　 　お世話になります。

>　送受信のやりとり記録にメモリ消費量を徹底的に出力して、果たしてどのタイミングでメモリを消費してるのかログで分かるようにする作戦を考えてみます。
>　（またログ取りお願いしないといけないですが）

　了解しました。
　お手数をお掛けして申し訳ありませんが、よろしくお願いいたします。

　それでは。
[ △ ]
RE:07596 「BeginMacro Memory Error」が発声するNo.07597
秀まるお2 さん　21/01/21 17:57　[ コメントを投稿する ]
　 　V6.98β4をアップロードしました。

32bit版:
https://hide.maruo.co.jp/software/bin3/hmmail698b4_signed.exe

音声化版:
https://hide.maruo.co.jp/software/bin3/hmmail698b4speech_signed.exe

64bit版:
https://hide.maruo.co.jp/software/bin3/hmmail698b4_x64_signed.exe

　「全般的な設定・上級者向け・デバッグ」の
　「デバッグレベル」の値を、

　1 ...  送受信のやりとり記録にメモリ使用量の記録が出る。
　2 ...  送受信のやりとり記録にメモリ空き容量の記録が出る。
　3 ...  「1」に加えてdump.txtに定期的メモリ使用量の記録が出る。
　4 ...  「2」に加えてdump.txtに定期的メモリ空き容量の記録が出る。

　って風にしました。とりあえず「1」か「3」で記録を取って欲しいです。

　出力される「MemUse:」または「MemAvail:」の値はメガバイト単位になりまして、小数点以下１桁まで出力しています。

　受信を３、４回繰り返して、その後もう一回順を実行してその後「直前のやりとり記録」を見て欲しいです。

　僕の所だと、たとえばgmailの18000通以上あるIMAP同期アカウントだと、こんな風になります。（MemUse:の記録付近の抜粋）

----------------------------------------------------------------------------
開始時刻: 2021/01/21 17:49:33
I Start MemUse:11.1
****IMAP4受信:xxxxxxxxxxx@xxxxx.com (高速化ON)
S C1 LIST "" *
I IMAPフォルダ一覧を取得中
R .........
S C2 SELECT "INBOX"
I 既存メールからUIDLを取得します
S C3 FETCH 1:* (UID)
I メール一覧を取得中(1/6)
.........
  C7 OK Success MemUse:11.2
I メール一覧を取得中(4/6) MemUse:11.3
S C9 FETCH 1:* (UID)
R * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotPhishing $Phishing) MemUse:11.2
.........
R C13 OK Success
I UIDL解析中... MemUse:11.3
I UIDL解析中(2) MemUse:11.4
I 0 / 0 済み (0Kバイト) MemUse:11.5
I 未読/既読の取得(1/3)
.........
  C19 OK SEARCH completed (Success)
終了時刻: 2021/01/21 17:49:37
MemUse:11.5
----------------------------------------------------------------------------

　一番最初のMemUseと一番最後のMemUseが違ってますが、もう一回受信すると、そのときの最初のMemUseは前回受信時の開始時のMemUseと同じになります。（僕の所だと）

　メモリの解放が多少遅延して実行されるのでその辺の誤差は発生しますが、とりあえず上記の通り、18000通程度のメールがサーバーにあっても、何も受信しない場合は最高でも0.4メガバイト程度（=400キロバイト程度）増えて、また減る、という程度にしかならないです。３０メガバイトも増えることはちょっとなんだか分からない所です。

　調べていただくの面倒でしたら、デバッグレベルを3にしてdump.txtを取って、それをまるごと送っていただいてもOKです。

　dump.txtの方には、

17:49:35.873 (10504) MemUse:11.5

　みたいな記録がいっぱい出る感じになります。メモリ使用量を時々チェックして変化してれば出力します。

　すみませんがお願いします。
[ △ ]
RE:07597 「BeginMacro Memory Error」が発声するNo.07598
陸 さん　21/01/21 21:04　[ コメントを投稿する ]
　 　お世話になります。

　ベータ版を入れて、試してみました。
　先ほど「dump.txt」を送付させていただきました。
　手違いでデバッグレベルを4にしてしまったのですが、3で撮り直した方がよければ再度送付いたします。
　あと、メモリ空き容量が170MB程度でソフトを終了してしまったので、そこまでの記録しか取れていないです。

　よろしくお願いいたします。
[ △ ]
RE:07598 「BeginMacro Memory Error」が発声するNo.07600
秀まるお2 さん　21/01/21 22:38　[ コメントを投稿する ]
　 　とりあえず、送っていたたいたdump.txtでたしかにメモリ空き容量がどんどん減ってることが確認できました。

20:39:05.286 ( 416) ImapIdle Delete
20:39:05.286 (2975) ImapIdle recycled
20:39:05.286 (6535) Send ThreadCreated 13608

　みたいな記録が大量にあるようで、この辺が原因のような気がしてきました。

　ImapIdleっていうのは定期受信での「IDLEコマンドを使って新着メールを監視する」のオプションがONの時に関係する処理になります。

　サーバーとやりとりする処理がマルチスレッドになってるんですが、そのスレッドを正常に終了できなかった場合にTerminateThreadで強制終了させる処理があって、その強制終了が働くとメモリリークが起きてしまいます。何らかの理由でImapIdleのリサイクルが多発しつつ、しかもスレッドの正常終了も失敗してる現象が起きてるのかなぁという気がします。

　もっと詳しく調べてなんとか対処したいと思います。
[ △ ]
RE:07600 「BeginMacro Memory Error」が発声するNo.07601
陸 さん　21/01/21 22:57　[ コメントを投稿する ]
　 　お世話になります。

　ありがとうございます。
　よろしくお願いいたします。

　それでは。
[ △ ]
RE:07601 「BeginMacro Memory Error」が発声するNo.07602
秀まるお2 さん　21/01/22 09:25　[ コメントを投稿する ]
　 　とりあえず先にオプションによる回避策がありそうでした。

　「全般的な設定・上級者向け・デバッグ・ソケット」の中に

　□ POP3コマンドの送信をシングルスレッドで行う

　があって、これをONにして、さらに

　□ 強制マルチスレッド送信

　がOFFのままでしたら、マルチスレッドを使わずに送信します。そうするとメモリリークが防げる可能性が高いです。

　とりあえずこの設定で使ってみて欲しいです。

　まだ調査中ですけども。
[ △ ]
RE:07602 「BeginMacro Memory Error」が発声するNo.07603
陸 さん　21/01/22 12:32　[ コメントを投稿する ]
　 　お世話になります。

　お教えいただいたオプションを変更したところ、確かにメモリ仕様がどんどん増える現象は解決しました。
　とりあえず、ご報告まで。

　それでは。
[ △ ]
RE:07603 「BeginMacro Memory Error」が発声するNo.07604
秀まるお2 さん　21/01/22 16:11　[ コメントを投稿する ]
　 　何度もすみません。

　一応オプションで回避できたということですが、そのままでも大丈夫ではありますが、やはりマルチスレッドの方がいいというか、データ送信で微妙にひっかかることが無くなっていいはずなので、そっちの方に戻していただいて、すみませんがまたテストお願いしたいです。

　今、V6.98β5をアップロードしました。これで直しています。

32bit版:
https://hide.maruo.co.jp/software/bin3/hmmail698b5_signed.exe

音声化版:
https://hide.maruo.co.jp/software/bin3/hmmail698b5speech_signed.exe

64bit版:
https://hide.maruo.co.jp/software/bin3/hmmail698b5_x64_signed.exe

　それで、定期受信をしばらく動かしてもらってdump.txtの記録を見て欲しいです。

　正常な場合だと、送信用のスレッドを終了させる処理の記録が、

15:57:22.821 (14773) SockSendThread exit 1
15:57:22.821 (14863) SockSendThread ThreadExit 9600
15:57:22.821 (2349 ) SockSendThread exit id=9600 time=0

　みたいに出てきます。「time=0」の所が終了にかかった時間（ミリ秒）で、僕の所だと0〜15にしかならないですが、時間がかかると、たとえば

15:40:51.242 (14764) tid=5476 SockSendThread exit 1
15:40:52.348 (2327) hthreadSend wait failed. code=258
15:40:53.357 (2327) hthreadSend wait failed. code=258
15:40:54.367 (2327) hthreadSend wait failed. code=258
15:40:55.378 (2327) hthreadSend wait failed. code=258
15:40:56.249 (14854) tid=5476 SockSendThread ThreadExit 5476
15:40:56.250 (2340) SockSendThread exit id=5476 time=5016

　みたいな感じの記録が出ます。もしも１０秒待ってもダメな場合は、

15:36:04.392 (2327) hthreadSend wait failed. code=258
15:36:05.400 (2327) hthreadSend wait failed. code=258
15:36:06.409 (2327) hthreadSend wait failed. code=258
15:36:07.417 (2327) hthreadSend wait failed. code=258
15:36:08.431 (2327) hthreadSend wait failed. code=258
15:36:09.443 (2327) hthreadSend wait failed. code=258
15:36:10.452 (2327) hthreadSend wait failed. code=258
15:36:11.462 (2327) hthreadSend wait failed. code=258
15:36:12.473 (2327) hthreadSend wait failed. code=258
15:36:13.479 (2327) hthreadSend wait failed. code=258
15:36:13.479 (2332) TerminateThread SockSendThread

　みたいに「TerminateThread」を使って強制終了させた記録が出てしまいます。（の場合はメモリリークする）

　dump.txtから正規表現grep検索で、

    "SockSendThread exit id|TerminateThread SockSendThread"

　を検索していただけると記録が一覧で見られます。

　すみませんがお願いします。

--------------------------------------------------------------
　前回送っていただいたdump.txtの記録だと、定期受信の場合に限ってスレッド終了（というか、スレッド終了を待つ処理）が時々失敗してるようでした。たぶんマシンが重くなると遅くなってタイムアウトしてたってことかと思います。β5では１０秒待つようにしましたが、β4以下は1秒までしか待たない処理になってました。
[ △ ]
RE:07604 「BeginMacro Memory Error」が発声するNo.07605
陸 さん　21/01/22 18:50　[ コメントを投稿する ]
　 　お世話になります。

　修正ありがとうございます。
　今のところ、問題ないようです。
　特にメモリ使用量が極端に増えるということもないようです。
　もし必要でしたら、ダンプファイルを送付させていただきます。
　今回は、大変お手数をおかけして、申し訳ありませんでした。

　以上、今後ともよろしくお願いいたします。
[ △ ]
RE:07605 「BeginMacro Memory Error」が発声するNo.07608
秀まるお2 さん　21/01/23 11:02　[ コメントを投稿する ]
　 　V6.98β5にてスレッド終了関係の処理をいろいろ見直して、タイムアウトを１０秒にしたのとは別に、即座に終了しない可能性が無いようにも直したので、それも効いてるかももしれません。

　もしもスレッドが即座に終了しないで２秒も３秒もかかってるとしたら、定期受信の最中に秀丸メール本体ウィンドウの操作が途中でひっかかる（短時間固まる）現象が出ると思います。もしそうなってるようでしたら、スレッドを毎回生成/終了させずにリサイクルさせるようにして回避可能ですが、それはちょっと修正量が多いので、今回正式版前ってことでやめときました。

　とりあえず良しとさせていただきます。
[ △ ]
[ 新規に投稿する ]