0

Windows でクラッシュするクロスプラットフォームの Firebreath プラグインに取り組んでいます。boost.asio を参照するクラスを含む静的ライブラリを使用します。このライブラリをプラグイン dll に対してリンクすると、io_service サブシステムと対話するとき (つまり、ソケットの構築中) にクラッシュが発生します。通常の実行可能ファイルに対して静的ライブラリをリンクすると、問題は発生しません。スタティック ライブラリの内容をプラグイン dll プロジェクトに直接コンパイルすると、クラッシュは発生しません。発生する。私は、Windows 上のビルド環境のすべての側面 (ビルド モード、Visual Studio のバージョンなど) が一貫していることを確認するために多大な努力を払ってきました。さらに、プラグイン dll コードが boost.asio サブシステムを認識できないように、boost.asio ヘッダーをファイアウォールで保護しました (残念ながら、vs2008 と vs2010 では効果がありません)。私が知る限り、ビルド環境が適切に動作するようにできる限りのことを行いましたが、問題は解決しません。

コミュニティは、潜在的なリスクや、問題を明らかにしたり解決したりする可能性のあるアプローチについてアドバイスを提供できますか?

4

2 に答える 2

1

スタティック ライブラリのリンクと DLL のロードで大きく異なる 2 つの点:

  • グローバルな初期化: DLL では、それらはすべて実行されます。スタティック ライブラリでは、リンカはオブジェクト ファイルが未解決の外部条件を満たす場合にのみオブジェクト ファイルを取り込むため、グローバル オブジェクトのコンストラクタまたは初期化式を使用して自身を登録するコンポーネントに依存するシステムは失敗します。

  • 共有 CRT: スタティック ライブラリでは、標準ライブラリへのすべての呼び出しがリンク時に解決され、メイン アプリケーションとライブラリ関数はすべて標準ライブラリの同じコピーを呼び出します。FILE*DLL では、標準ライブラリのコピーを 2 つ持つリスクがありますが、ライブラリとアプリケーションの間で標準ライブラリ オブジェクト ( 、std::string、またはmalloc/freeのペアなど)を共有しないように注意すれば問題ありません。

2番目のことは、あなたを噛んでいる可能性が最も高いです. それを修正する怠惰な方法があります: 標準ライブラリ DLL を使用し、それを修正するより良い方法: メモリとオブジェクトの有効期間を把握し、一方に割り当ててもう一方に解放しようとしたり、C++ クラス レイアウトを全体で共有したりしないでください。境界。仮想機能は、境界を越えて正常に機能します。

「より良い」方法の利点は、プラグインを任意のバージョンのコンパイラでビルドできることです。これは、開発サイクルの後半でのメンテナンスにとって大きな問題になります。

于 2012-02-25T18:25:13.197 に答える
0

FireBreath プラグインの準備スクリプトで、WITH_DYNAMIC_MSVC_RUNTIME フラグをオンにしてみてください。

于 2012-05-21T06:47:55.260 に答える