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

Question

Potrzebuję pomocy z tym wyjątkiem, implementuję wtyczkę NPAPI, aby móc używać lokalnych gniazd z rozszerzeń przeglądarki, w tym celu używam frameworku Firebreath.

Dla gniazd i połączeń Używam funkcji Boost asio z połączeniami asynchronicznymi i pulą wątków 5 wątków roboczych. Mam również termin na wątek, aby wprowadzić limit czasu transmisji.

Moje rozszerzenie workflow z wtyczką jest jak ten:

1. Otwarte gniazdo 1 (ta rozpoczyna async_receive a termin async_wait)
2. pisać w gnieździe 1

3. uzyskać odpowiedzi 1

4. Otwórz inne gniazdo 2

5. Wri Te w gnieździe 2

6. gniazdo zapisu 1

7. pobliżu gniazda 1 (socket.cancel() deadline.cancel() socket.shutdown(), gniazdo uwalnianiu).

8. odpowiedź Get 2

9. gniazdo Zapis 2
10. Zamknij gniazdo 2

jak wszystko jest język krzyż i asynchroniczny jest naprawdę trudne do debugowania, ale wszystkie otwarte, zapisu lub blisko nazywane są z javascript oraz odczyt z gniazda 1, które wywołuje otwarte 2, wpisz 2, napisz 1 i zamknij 1 w tej kolejności.

Może evrything mówię jest niezwiązane jak stos wywołań, gdy jest wyjątek nie wykazuje żadnej z moich funkcji, a jedynie pokazać, że jest wewnątrz malloc że nazywa _heap_alloc_dbg_impl

Ponieważ jest to zwykle nie w Drugi lub trzeci pełny cykl i wydaje się, że dzieje się między krokami 5 i 7.

Ale myślę, że to musi być tak samo związane, jak robienie wszystkiego za pomocą jednego wątku roboczego po prostu rozbija się z wyjątkiem w pierwszym cyklu.

Jestem otwarty na opublikowanie więcej kodu informacyjnego, jeśli jest to potrzebne.

Aktualizacja 1:

Aktualizacja 2:

Istnieje 10 wątki są uruchamiane z:

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)); 
} 

The 11th _threadstartex nie wiem kto go uruchomił

W innym wątku (nie tym, który twierdzi, że VS powoduje awarię) jest proces join_all(), ponieważ moja klasa jest niszczona, ale myślę, że nie powinna, więc może ta awaria jest spowodowana innym wyjątkiem i Firebreath proces zamykania wszystkiego, gdy się zawiesza.

Answer 1

Znalazłem błędy, kontynuując sprawdzanie innych wątków. Zauważyłem, że moja główna klasa, którą wywoływał Firebreath, była w trakcie niszczenia. Sprawdzając trochę więcej Stwierdziłem, że to była całkowicie moja wina, że ​​mam klasę do przechowywania informacji o gniazdach, które muszą używać funkcji w głównej klasie (nie podobało mi się to, ale był to jedyny sposób, w jaki znalazłem to użycie) więc dodałem shared_ptr do głównej klasy. Więc jeśli po zniszczeniu tych obiektów SocketInfo, ponieważ nie było żadnych innych, liczba ptr ref osiągnęła 0, a główna klasa została zniszczona.

Co jest zabawne, to to, że gniazda zwykle zamykają się normalnie po użyciu, więc nie widzę powodu, dla którego nie byłby on uruchamiany, gdy nie byłyby otwarte gniazda i zdarzał się tylko wtedy, gdy 2 gniazda były otwierane i zamykane w rzędzie.

W każdym razie miałem również błąd shared_from_this z obsługą terminu, ale wydawało mi się to niezwiązane.

A teraz wygląda na to, że działa zgodnie z oczekiwaniami z dowolną liczbą wątków.