MFC(VS2015) + boost::Logで終了時に例外が発生

Question

mfcアプリにboost::Logを組み込もうとしています。ログの保存などロギングに関する動作は問題ないのですが、アプリ終了時に一般保護例外が出てしまいます。(boostのバージョンは1.60.0)
例外が発生する箇所は、boostのsrw_lock.hppの

BOOST_FORCEINLINE VOID_ AcquireSRWLockExclusive(PSRWLOCK_ SRWLock)
{
    ::AcquireSRWLockExclusive(reinterpret_cast< ::_RTL_SRWLOCK* >(SRWLock));
}

で、::AcquireSRWLockExclusiveでSRWLockが0xddddddddと不正なアドレスを示しているために一般保護例外になっているようなのです。Visual Studioの呼出履歴を見ると

LPCExplorer.exe!boost::detail::winapi::AcquireSRWLockExclusive(boost::detail::winapi::_RTL_SRWLOCK * SRWLock) 行 82	C++
LPCExplorer.exe!boost::log::v2s_mt_nt6::aux::light_rw_mutex::lock() 行 67	C++
LPCExplorer.exe!boost::log::v2s_mt_nt6::aux::exclusive_lock_guard<boost::log::v2s_mt_nt6::aux::light_rw_mutex>::exclusive_lock_guard<boost::log::v2s_mt_nt6::aux::light_rw_mutex>(boost::log::v2s_mt_nt6::aux::light_rw_mutex & m) 行 102	C++
LPCExplorer.exe!boost::log::v2s_mt_nt6::core::remove_all_sinks() 行 511	C++

となっていて、終了時のboost.Logの後片付けで発生しているんだろうなぁまでは分かるんですが、それ以上はboost.Logの内部の仕組みをよく理解してないので追いきれてません。

どなたか、わかる方がいれば助かります。
ちなみに、ロガーはクラス化してあって、MFC以外のアプリ(Win32)では問題なく動作しています。

MFC + Boost.Logは無理なんでしょうかね？（MFCを辞めたいのは山々なんですが、このアプリをWin32で作りなおすのは時間とコストを考えると事実上不可能に近い・・・）

Answer 1

こんにちは。ちょっと長くなるので、こちらから。

ソースを追いかけてみたのですが、私もyohhoyさんの見解に賛成です。

::AcquireSRWLockExclusiveでSRWLockが0xddddddddと不正なアドレスを示している

このSRWLockはlog\core\core.hpp内で定義されているcoreクラスの実体(m_impl)のメンバm_mutexです。
超絶ややこしくて読みそこなっているかも知れませんが、m_implはstaticに獲得されるシングルトンでした。
これは、main()関数終了後制御できないタイミングで自動的に解放されます。・・・①

そして、PineMatsuさんのロガークラスをMFCのクラス内で獲得／解放していた場合、MFCのインスタンスが解放されるタイミングで解放されます。
そのMFCのインスタンスがどこで獲得されているのか分かりませんが、もし、グローバル変数的にstaticに獲得されている場合、main()関数終了後の制御できないタイミングで解放されます。②

つまり、①→②の順序で解放された場合、②のタイミングでremove_all_sinks()が呼ばれますが、①にて既にm_implの実体が解放されているため、冒頭の例外が発生するのだと思います。

対策は、yohhoyさんの言う通り、下記が正解のように感じます。（私も実動作させたわけではないので確信まではないですが。）

単にmain関数終了直前にremove_all_sinks()呼び出しで良いかもしれません（実動作させたわけじゃないので自信ナシ）

なお、MFCのインスタンス解放処理内で、ロガークラスがboost::logを操作すると何か問題が起きる可能性を懸念します。デストラクタ内では後始末だけに限定し、ログを取るようなことはしない方がよいかもしれません。

Comments

[PineMatsu]

解析ありがとうございます。（よくあんなややこしいのを読めますね。尊敬します）
ロガークラスはCWinAppを継承したクラスで保持しています。
yohhoyさんのコメントにも書きましたが、ExitInstance()でremove_all_sinks()を呼ぶようにしてやったら、メモリリークも含めてうまくいきました。
これで、Win32アプリとMFCアプリ両方で共通に使えるロガークラスが出来そうです。

Answer 2

Boost.Logドキュメントに Why my application crashes on process termination when file sinks are used? という情報がありました。

MFCアプリケーション終了の直前に、下記コードを呼び出してみたらどうでしょう？

logging::core::get()->remove_all_sinks();

Comments

[PineMatsu]

remove_all_sinks()はクラスのデストラクタで呼び出していたのですが、呼出履歴にあるようにこのremove_all_sinks()の中で例外が起こっているようでした。
それで、ロガーのインスタンスをメインクラスのメンバーではなく、グローバルでポインターとして定義し、new,deleteで生成と破棄をメインの最初と最後に置くようにしたところ、例外は出なくなりました。
しかし、終了時にロガークラス内でsink追加した時に指定した日付指定文字列やベースファイル名などがメモリーリークするようになりました。むむむ・・・。
なんかもう少しのような気がするのですが・・・。

[yohhoy]

今回の問題は、main関数を抜けた後にremove_all_sinks()が呼ばれたことが原因のように_見えます_。グローバルロガーを生ポインタ保持すると別の問題が出そうですし、単にmain関数終了直前にremove_all_sinks()呼び出しで良いかもしれません（実動作させたわけじゃないので自信ナシ）

参考：http://www.boost.org/doc/libs/1_60_0/libs/log/doc/html/log/rationale/init_term_support.html

「終了時のメモリリーク」はどのように検出されたのでしょう？
プロセス終了時の内部メモリリーク（≠外部リソースのリーク）であれば実用上問題はありませんから、無視するという戦略もあります。

[PineMatsu]

なるほど、ありがとうございます。デストラクタではなくremove_all_sinks()の積極的な呼び出しをやってみます。
メモリリークは、MFCで通常やっているやり方です。外部リソースではないので仰るとおり実用上は問題なさそうですね。

[PineMatsu]

生ポインター保持をやめて、ExitInstance()でremove_all_sinks()を呼び出すようにしたら例外もメモリリークも発生しなくなりました。

ありがとうございました！助かりました。