boost::exception_detail::clone_impl‹boost::exception_detail::error_info_injector‹boost::thread_resource_error› ›

Мне нужна помощь с этим исключением, я внедряю плагин NPAPI, чтобы иметь возможность использовать локальные сокеты из расширений браузера, для этого я использую платформу Firebreath.

Для сокета и подключения я использую Boost asio с асинхронными вызовами и пулом из 5 рабочих потоков. Также у меня есть крайний срок для каждого потока для реализации тайм-аута передачи.

Мой рабочий процесс расширения с плагином выглядит следующим образом:

  1. Откройте сокет 1 (это запускает async_receive и крайний срок async_wait)
  2. Запись в сокете 1

  3. Получить ответ 1

  4. Откройте другой сокет 2

  5. Запись в сокете 2

  6. Запись сокета 1

  7. Закройте сокет 1 (socket.cancel(), dead.cancel(), socket.shutdown(), освобождение сокета).

  8. Получить ответ 2

  9. Запись сокета 2
  10. Закрыть сокет 2

Поскольку все на разных языках, а асинхронность действительно сложно отлаживать, но все операции открытия, записи или закрытия вызываются из javascript, а чтение из сокета 1 вызывает открытие 2, запись 2, запись 1 и закрытие 1 в указанном порядке.

Возможно, все, о чем я говорю, не имеет отношения к делу, поскольку стек вызовов при возникновении исключения не показывает ни одной из моих функций, а показывает только, что он находится внутри 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 все, когда он падает.


c++ visual-c++ boost-thread boost-asio firebreath
person frisco    schedule 21.03.2013    source источник
comment
Где выбрасывается исключение? Разместите код.   -  person Sam Miller    schedule 21.03.2013
comment
Сколько рабочих потоков существует? Похоже, темы, которые вы начинаете, никогда не завершатся.   -  person Drew Dormann    schedule 21.03.2013
comment
Добавлено изображение с кодом, стеком вызовов и потоками. Я не могу увидеть исключение, я просто получаю сообщение об исключении с вариантами прерывания или продолжения, и когда я прерываю это состояние, обратите внимание, что в стеке вызовов нет фрейма с моим кодом (мои классы SocketInfo , SocketsApi, Base64), в другом потоке видно, что объект npapi был уничтожен и выполняет {m_threadGroup.join_all();}, но его не следует уничтожать в этот момент, поэтому, возможно, VS ломается после другого исключение заставило плагин начать уничтожение, я понятия не имею, как работает FB   -  person frisco    schedule 21.03.2013

Ответы (1)


arrow_upward
12
arrow_downward

Я нашел ошибки, продолжая проверять другие потоки. Я обнаружил, что мой основной класс, который вызывал Огненное Дыхание, находился в процессе уничтожения. Изучив немного больше, я обнаружил, что это полностью моя вина. У меня есть класс для хранения информации о сокетах, которая необходима для использования функции в основном классе (мне это не понравилось, но это был единственный способ, которым я нашел его использовать) поэтому я добавил shared_ptr в основной класс. Итак, если после уничтожения одного из этих SocketInfo объектов, поскольку других не было, счетчик ссылок ptr достиг 0, и основной класс был уничтожен.

Что забавно, так это то, что сокеты обычно нормально закрываются после использования, поэтому я не вижу причин, по которым это не срабатывало, когда сокеты не были открыты, и происходило только тогда, когда 2 сокета открывались и закрывались подряд.

Во всяком случае, у меня также была ошибка shared_from_this с обработчиком крайнего срока, но это казалось не связанным.

И теперь кажется, что он работает, как и ожидалось, с любым количеством потоков.

person frisco    schedule 21.03.2013
comment
Я отредактировал это, чтобы удалить извиняющийся тон, поэтому настоятельно рекомендую ответить на ваш собственный вопрос. Так что +1 за ответ, который, надеюсь, поможет другим. - person Sam Miller; 22.03.2013