#直接の問題は、プロセスハンドルをMsgWaitForMultipleObjectsに渡すと"The handle is invalid"でエラーになることで、調べてみると当初ちゃんとした値を返してたGetProcessIdが0を返すようになっているという。
#で、どうもプロセスがまだ走っててもGetProcessIdが0を返すようになるみたいなんですね。0を返した時点でのGetLastErrorを見てみようか
#GetProcessIdが0を返した時点ではGetLastErrorも0だなあ。
#いずれにせよpidは問題じゃなくて、プロセスハンドルがなぜどういうタイミングでinvalidになるのかってことだなあ
#アンチウイルスソフトがなんかしてるとかいうオチはないかな…
#あー、プロセスを砂箱内で仮実行するみたいなやつですか。Win10のDefenderなんだけど、Real-time protectionてやつは切っても同じだなあ。とりあえず仮でコミットしていろんな環境で試してもらった方がいいかも。
#「既にcloseされたファイルハンドルに関連するfdを_close()してた」というバグを直したら問題が消失した。元のファイルハンドルに使われた領域がプロセスハンドルで再利用されてて、_close(fd)した際にその領域を壊した、と考えれば辻褄が合う。
#そうだとするとGetProcessIdが生きてるプロセスハンドルに対して0を返す、というのも想定されてないことであってドキュメントを疑ったのは済まなかった。
#該当ファイルハンドルは陽にCloseHandleを呼び出すのではなく、DuplicateHandleのDUPLICATE_CLOSE_SOURCEで暗黙にクローズされていたのが盲点じゃった。
#とはいえ_close(fd)みたいな操作で一見関係ないとこが壊れるってのもなかなかのトラップであるな。
#_close()はエラーを返してたのでちゃんとチェックしてれば早期に気づけたはずではあるけれど、_close()がエラー返した時点で既に関係ないプロセスハンドルが壊れてるんで、エラーを捕まえたとしてもその後リカバーできなかっただろうな。
Gauche > Archives > 2016/08/06