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

Question

Ho bisogno di aiuto con questa eccezione, sto implementando un plugin NPAPI per poter usare i socket locali dalle estensioni del browser, per farlo uso la struttura di Firebreath.

Per socket e connettività Sto usando Boost asio con chiamate asincrone e un pool di thread di 5 thread di lavoro. Inoltre ho una scadenza per thread per implementare un timeout di trasmissione.

mio flusso di lavoro interno con il plugin è come questo:

1. aperta presa 1 (questo avvia un'async_receive e l'async_wait termine )
2. scrittura nella presa 1

3. Get risposta 1

4. Aprire un'altra presa 2

5. Wri te nella presa 2

6. Write presa 1

7. Chiudi presa 1 (socket.cancel(), deadline.cancel(), socket.shutdown(), presa rilascio).

8. risposta Get 2

9. Scrivi presa 2
10. Chiudi presa 2

Come tutto è linguaggio croce e asincrone è davvero difficile eseguire il debug, ma tutti aperti, scrivere o chiudere sono chiamati da JavaScript e la lettura dal socket 1 che chiama open 2, scrive 2, scrive 1 e chiude 1 in questo ordine.

Forse tutto ciò di cui sto dicendo è indipendente, in quanto lo stack di chiamate quando viene generata l'eccezione non mostra nessuna delle mie funzioni e mostrare solo che è all'interno di un malloc che chiama _heap_alloc_dbg_impl

Come è di solito non riesce a il 2 ° o 3 ° ciclo completo e sembra che avvenga tra i passaggi 5 e 7.

Ma, penso che debba essere collegato asio come fare tutto con un singolo thread di lavoro appena si blocca con l'eccezione nel primo ciclo.

Sono aperto a pubblicare ulteriori informazioni codice se ne avete bisogno.

Update 1:

Aggiornamento 2:

Ci sono 10 thread sono lanciati con:

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

Il _threadstartex 11 ° non so chi l'ha lanciato

Su un altro thread (non quello che VS sostiene come causa dello schianto) c'è un join_all() in corso perché la mia classe viene distrutta ma penso che non dovrebbe, quindi forse questo crash è dovuto ad un'altra eccezione e al Firebreath processo per chiudere tutto quando si blocca.

Answer 1

Ho trovato gli errori continuando a ispezionare gli altri thread. Ho scoperto che la mia classe principale che Firebreath stava invocando era in procinto di essere distrutta. Ispezionando un po 'di più ho scoperto che era totalmente colpa mia avere una classe per archiviare le informazioni sui socket che avevano bisogno di usare una funzione nella classe principale (non mi piaceva ma era l'unico modo in cui ho trovato di usarlo) quindi ho aggiunto un shared_ptr alla classe principale. Quindi, se dopo aver distrutto gli oggetti SocketInfo come non ce ne fossero altri, il conteggio ref ptr ha raggiunto 0 e la classe principale è stata distrutta.

cosa è divertente è che le prese di solito vicino normalmente dopo essere stato utilizzato in modo non vedo alcun motivo per cui questo non è stato innescato quando non c'erano i socket aperti ed è successo solo quando 2 prese dove aperti e chiusi in una fila.

In ogni caso ho avuto anche un errore shared_from_this con il gestore di scadenza ma ciò sembrava non correlato.

E ora sembra che funzioni come previsto con qualsiasi numero di thread.