[ 新規に投稿する ]
V8.98β8No.10395
秀丸担当 さん　21/05/17 09:36　[ コメントを投稿する ]
　
V8.98β8を公開しました。

以下のページの「先行開発バージョンはこちら」からダウンロードできます。
https://hide.maruo.co.jp/software/hidemaru.html

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

64bit版：
https://hide.maruo.co.jp/software/bin3/hm898b8_x64_signed.exe
[ △ ]
RE:10395 V8.98β8No.10397
こみやんま さん　21/05/17 11:06　[ コメントを投稿する ]
　
■64bitとX64MACRO関連の挙動確認できました。

bool型、int, long, IntPtr(=nint), で「1とCOMでMarshalされるもの」を定義しておけば、64bitの数値が渡るようになりました。
(decimal型では反応しなかったですが、COMの型とはおそらくMarshalの規約がないので、1を返してもCOM側が1と解釈できないのだと思います)


■keepdll文
Destroy(Detach)系が呼ばれていることを確認しました。(新たなReason値(=4?)になっているかはまだ未確認です)
ただ、これを指定していたとしても、Hidemaru_EvalMacroで事故った時、秀丸がfreedll相当を実行しますが、実際には解放されないかも？
 何かを参照している状態になっていて、Windowsの方がdllの実際の解放を止めている...かも？ ちょっとマイクロなサンプルを用意していろいろと確認してみます。）

あと、β版の秀丸サイトの更新内容の文章でsetcomdetach**method**をsetcomdetach**reason**と書きミスしているっぽいです。

■Hidemaru_EvalMacroでミスった時、Falseが返ってきていることを確認しました。
[ △ ]
RE:10397 V8.98β8No.10398
秀丸担当 さん　21/05/18 09:07　[ コメントを投稿する ]
　
早速のご確認ありがとうございます。
改版履歴は確かにその通りでした。訂正するようにします。
[ △ ]
RE:10395 Hidemaru_EvalMacro エラー時に、マクロ解放処理のNo.10399
こみやんま さん　21/05/23 05:33　[ コメントを投稿する ]
　 Hidemaru_EvalMacro にて「型」エラーなど、マクロがストップしてしまうような
エラーが起きた際、dll解放も含めて解放系処理の一部が実行されていないように思えます。

■エラー概要
・Hidemaru_EvalMacro内でマクロストップを伴うエラーの際、
　「解放系処理の一部(※1)」がなされない疑惑。
　（おそらく秀丸v8.66以降ずっとあるバグ）

・※1は、dllの解放だけではなく、マクロハンドル解放処理、マクロキャッシュ解放処理など、
　何か通過すべき「一連の解放処理」がごっそり抜けているように思えます。

・ミクロな処理を組んでみたところ、
　dllが解放されない現象が100％発生するサンプルとなりました。

　（比較的大型のソースでよければ、Hidemaru_EvalMacroのエラーがきっかけで
　　編集ペインが機能しなくなるのを100％再現できるソースをお渡しできます。ただしおそらくは原因の根は今回のミニマムサンプルと同じではないかと推察します）

■再現ソースなど
・専用リポジトリ
　https://github.com/komiyamma/hidemaru_eval_bug

・.dllソース(C++)
　https://github.com/komiyamma/hidemaru_eval_bug/blob/main/Dll2/dllmain.cpp
　(Dll2.dll)としてコンパイル

・.macソース
　https://github.com/komiyamma/hidemaru_eval_bug/blob/main/Debug/DLL2.mac

■「.dllが解放される、解放されない、の確実な切り替えポイント
　
・https://github.com/komiyamma/hidemaru_eval_bug/blob/main/Dll2/dllmain.cpp
　の67行目、
　int success2 = EvalMacro(LR"RAW(#r = dllfuncw(#dll, "DoSomething2nd", message(10));)RAW");

　の状態で、DLL2.macを実行すると、いわゆる秀丸マクロの型エラー表示の後、
　マクロは終了するが、dllは解放されないままとなる。
　(秀丸が独自に呼び出しているデタッチ関数などはコールされるが、dllは解放されない）

　一度秀丸を全て終了し、改めて

　同67行目を
　int success2 = EvalMacro(LR"RAW(#r = dllfuncw(#dll, "DoSomething2nd", message("10"));)RAW");
　と修正すると文法が正しくなる。
　コンパイルしなおし、改めてDLl2.macを実行すると、
　今度はdllは解放される。

　この「差」はFreeLibraryを実行しているが失敗している、とかではなく、
　マクロ停止系エラーの際に、単純にマクロ解放処理の一部の「実行もれ」があるようにように思えます。
[ △ ]
RE:10399 Hidemaru_EvalMacro エラー時に、マクロ解放処理のNo.10400
こみやんま さん　21/05/23 15:50　[ コメントを投稿する ]
　 こちらの createobject + .NET4版で少しソースが長いものを提供します。
（余分なものを排除して全ソースの数％ぐらいまで縮小しましたがそれでもまだややながい…)
COMではなく、loaddll + C++ native で同様の処理をしても、同様になることが確認できています。
（この同様になるネイティブ実装はまた改めてソースを絞って提供します。ネイティブの方がデバッグがしやすいかもしれないので）

■発生する症状
　マクロを秀丸の「メニュー」から、ClassLibrary24.mac を、３回ほど実行すると、
　編集領域で編集できなくなり、編集できなくなった後は、秀丸の操作自体全く効かなくなる。
　(秀丸x86版/秀丸x64版両方で再現する)

■リポジトリ
　https://github.com/komiyamma/hidemaru_eval_bug2

■C#ソース
　・https://github.com/komiyamma/hidemaru_eval_bug2/blob/main/ClassLibrary24/Class1.cs
　・https://github.com/komiyamma/hidemaru_eval_bug2/blob/main/ClassLibrary24/HmNetPInvokeForCreateObject.cs
　・https://github.com/komiyamma/hidemaru_eval_bug2/blob/main/ClassLibrary24/Properties/AssemblyInfo.cs
　.NET4.8コンパイル

■.macソース
　https://github.com/komiyamma/hidemaru_eval_bug2/blob/main/ClassLibrary24/bin/Debug/ClassLibrary24.mac
[ △ ]
RE:10400 Hidemaru_EvalMacro エラー時に、マクロ解放処理のNo.10401
こみやんま さん　21/05/23 15:53　[ コメントを投稿する ]
　 追記。
Class1.cs が
Hm.Macro.Statement("message", "10");
ならば、マクロが正しいため、何回実行しても問題はなし。

Hm.Macro.Statement("message", 10);
ならば、Hidemaru_EvalMacro内の型エラーを契機に何かが解放されない（もしくはロック？）されてゆき、
数回実行の後、秀丸エディタの編集ペインが操作不能に、その後は秀丸全体が操作不能となる。
[ △ ]
RE:10401 ３つ目のサンプルNo.10402
こみやんま さん　21/05/23 18:38　[ コメントを投稿する ]
　 Hidemaru_EvalMacroの失敗を契機として
編集ペイン操作不能⇒秀丸操作不能への再現率が非常に高い「ネイティブ」でのソースを
hmPython3からかなりシュリンクして構築しました。
まだやや贅肉はありますが、このくらいまで絞ってあれば、
秀丸担当さんの方でデバッグがしやすいかと思います。

■発生する症状
　マクロを秀丸の「メニュー」から、hmError.mac を、1回もしくは2回ほど実行すると、
　編集領域で編集できなくなり、編集できなくなった後は、秀丸の操作自体全く効かなくなる。

■再現ソースなど
・専用リポジトリ
　https://github.com/komiyamma/hidemaru_eval_bug3

・ソースは多いので、
　上記githubリポジトリの「Code↓」からソリューション、プロジェクト、ソースなど一式ダウンロードして
　Visual Studio でコンパイルしてください。2017で作っています。

・.macソース
　https://github.com/komiyamma/hidemaru_eval_bug3/blob/main/Debug/hmError.mac

（※備考）
　Pythonといった文字がソースに踊っていますが、pythonは無関係です。
　hmPython3をシュリンクしてこのテスト用のプログラムを制作したので
　pythonというコメント・関数名・ファイル名が残っているだけで
　このプログラムではpythonは一切関係ありません。


■フリーズする、しないの切り替えポイント
　python_engine.cpp 内の 45〜47行目
  https://github.com/komiyamma/hidemaru_eval_bug3/blob/main/hmPython3/python_engine.cpp

 Hidemaru::Macro_SetIntVar(L"#TEST1", 10);
 Hidemaru::Macro_Eval(L"message #TEST1");
 Hidemaru::Macro_SetIntVar(L"#TEST1", 0);

　は、message 10 といったこととなり、型エラーののち、これがきっかけで、
　編集ペインは操作不能に、⇒ 秀丸自体操作不能になっていきます。

 Hidemaru::Macro_SetStrVar(L"$TEST1", L"10");
 Hidemaru::Macro_Eval(L"message $TEST1");
 Hidemaru::Macro_SetIntVar(L"$TEST1", L"");

　にした場合は、文法エラーなどはないため、特に問題は発生しません。



私から提供できるバグサンプルは
https://github.com/komiyamma/hidemaru_eval_bug
https://github.com/komiyamma/hidemaru_eval_bug2
https://github.com/komiyamma/hidemaru_eval_bug3
と以上３種類となります。
[ △ ]
RE:10402 ３つ目のサンプルNo.10403
こみやんま さん　21/05/23 21:22　[ コメントを投稿する ]
　 一部記載ミスがあったので、投稿を修正します。

-----------------------------------------------Hidemaru::Macro_SetStrVar(L"$TEST1", L"10");
 Hidemaru::Macro_Eval(L"message $TEST1");
× Hidemaru::Macro_SetIntVar(L"$TEST1", L"");
〇 Hidemaru::Macro_SetStrVar(L"$TEST1", L"");

　にした場合は、文法エラーなどはないため、特に問題は発生しません。
-----------------------------------------------
[ △ ]
RE:10403 ３つ目のサンプルNo.10405
秀丸担当 さん　21/05/24 10:18　[ コメントを投稿する ]
　
いろいろご指摘ありがとうございます。

FreeLibraryについては、文法エラー等のエラーになったときは、DLL関数を抜けたらそれ以上マクロの続行はしないことになっていて、.macに書かれたfreedllは実行されず、keepdllの指定によって後処理が行われます。
後処理ではsetdlldetachfuncの関数が呼ばれますが、FreeLibraryはその時点では行われませんでした。
このあたりは非常にデリケートなことになっているのですが、過去ログ2016の9011番書き込みの天翔記.jpさんとのやりとりによって、個別loaddllが自動開放される場合については、能動的にFreeLibraryはせず、OleUnnitializeも終わってプロセス終了時のWindowsによる解放に任せることになっています。
（さらに、個別DLLではないloaddll文によるロードの場合はまたタイミングが違ったりします）

keepdll #dll,0;の場合は、一応自動開放のやり方にあてはまることにしていたのですが、freedllによるマクロ実行での解放ではFreeLibraryしています。
keepdll #dll,0;は明示的なので、FreeLibraryするように変更します。
もしかしたら状況によって変わるかもしれないので、確実に後処理するためにはsetdlldetachfuncで、FreeLibraryのタイミングは仕様としてそう定めているということにはしたくないところです。


もう一件の入力ができない状況になるのも再現できました。
詳しい情報ありがとうございます。
調べるのがだいぶん手こずったのですが、Windows 10 Version 2004(20H1)の新しいMicrosoft IMEでそうなることがわかりました。
従来のMicrosoft IMEにすたり、Google日本語入力にすると大丈夫です。
原因はマクロの文法エラーによってその後のマクロの中断するとき、ウィンドウのメッセージを捨てていることにありました。メッセージを捨てるのは１回だけですが、一度そういう状況になると、IMEによって全部の入力がフィルタリング(?)されてしまい届かないようです。
対応してV8.98β9で修正しています。
[ △ ]
RE:10405 ３つ目のサンプルNo.10406
こみやんま さん　21/05/24 13:57　[ コメントを投稿する ]
　 >keepdll #dll,0;は明示的なので、FreeLibraryするように変更します。

>対応してV8.98β9で修正しています。

「Win10 Pro 21H1」と「Windows Server 2019 Datacener 1809」の両方でβ９で挙動が変わることを確認しました。

うおお!! hmPython3とhmPeachがめっちゃ便利になったかもｗ
[ △ ]
[ 新規に投稿する ]