7

この例外については、助けが必要です。ブラウザ拡張機能のローカルソケットを使用できるように、NPAPIプラグインを実装しています。これを行うには、Firebreathフレームワークを使用しています。

ソケットと接続性については、非同期呼び出しと5つのワーカースレッドのスレッドプールでBoostasioを使用しています。また、送信タイムアウトを実装するためのスレッドごとの期限があります。

プラグインを使用した拡張ワークフローは次のとおりです。

  1. ソケット1を開きます（これにより、async_receiveと期限async_waitが開始されます）
  2. ソケットに書き込む1

  3. 応答を取得1

  4. 別のソケットを開く2

  5. ソケット2に書き込みます

  6. 書き込みソケット1

  7. ソケット1を閉じます（socket.cancel（）、deadline.cancel（）、socket.shutdown（）、ソケットリリース）。

  8. 応答を取得2

  9. 書き込みソケット2
  10. ソケット2を閉じます

すべてがクロスランゲージであり、非同期はデバッグが非常に難しいため、すべてのopen、write、またはcloseはjavascriptから呼び出され、ソケット1からの読み取りはopen 2、write 2、write 1、close1の順に呼び出されます。

たぶん、私が言っているevrythingは、例外がスローされたときの呼び出しスタックが私の関数を表示せず、それがmalloc呼び出しの内部にあることを示すだけなので、無関係です_heap_alloc_dbg_impl

通常、2番目または3番目の完全なサイクルで失敗し、ステップ5と7の間に発生するようです。

ただし、最初のサイクルを除いて、単一のワーカースレッドですべてを実行するとクラッシュするだけなので、asioに関連している必要があると思います。

必要に応じて、より多くの情報コードを公開できます。

アップデート1：

壊れたときのVS

アップデート2：

10個のスレッドが起動されます：

workPtr.reset( new boost::asio::io_service::work(io_service));

for ( int i = 0; i < 10; ++i) {
    m_threadGroup.create_thread( boost::bind(&boost::asio::io_service::run, &io_service) );
}

11番目の_threadstartex誰が起動したのかわかりません

別のスレッド（VSがクラッシュを引き起こしていると主張しているスレッドではない）ではjoin_all()、クラスが破棄されているために処理中ですが、破棄すべきではないと思います。したがって、このクラッシュは、別の例外とFirebreathプロセスがすべてを閉じることが原因である可能性があります。クラッシュしたとき。

4

1 に答える 1

12

他のスレッドを調べ続けることでエラーを見つけました。Firebreathが呼び出していた私の主要なクラスは、破壊されている途中であることがわかりました。もう少し調べてみると、それは完全に私のせいであることがわかりました。プリンシパルクラスの関数を使用するために必要なソケット情報を格納するためのクラスがあります（私はそれが好きではありませんでしたが、それを使用する唯一の方法でした）そこでshared_ptr、プリンシパルクラスにを追加しました。したがって、SocketInfo他に存在しなかったためにこれらのオブジェクトを破棄した後、ptr ref countが0に達し、プリンシパルクラスが破棄されていた場合。

面白いのは、通常、ソケットは使用後に正常に閉じるので、ソケットが開いていないときにこれがトリガーされず、2つのソケットが連続して開閉したときにのみ発生した理由はわかりません。

とにかくshared_from_this、締め切りハンドラーにもエラーがありましたが、それは無関係のようでした。

そして今では、任意の数のスレッドで期待どおりに機能しているようです。

于 2013-03-21T18:55:43.057 に答える