boost :: exception_detail :: clone_impl <boost :: exception_detail :: error_info_injector <boost :: thread_resource_error>>

Question

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

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

Мой расширение рабочего процесса с плагином как это:

1. Открытое гнездо 1 (это начинает async_receive и срок async_wait)
2. Запись в гнезде 1

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

4. Открыть другую розетку 2

5. Wri т.е в гнезде 2

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

7. Закрыть сокет 1 (socket.cancel(), deadline.cancel(), socket.shutdown(), розетка релиз).

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

9. Написать гнездо 2
10. Закрыть гнездо 2

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

Может быть Evrything я говорю не имеет никакого отношения, как стек вызовов, когда исключение генерируется не показывает какой-либо из своих функций, и только показать, что он находится внутри malloc, который вызывает _heap_alloc_dbg_impl

Как это обычно не удается в 2-й или 3-й полный цикл, и кажется, что это происходит между этапами 5 и 7.

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

Я открыт для публикации более подробной информации, если вам это нужно.

Update 1:

Update 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 чтобы закрыть все, когда он падает.

Answer 1

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

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

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

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