Keine Ausnahme von boost :: asio :: io_service :: run

Question

Ich habe einen TCP-Server auf boost :: asio, es wartet auf eine Verbindung und nach dem Abrufen beginnt es Datenblöcke mit boost :: asio :: write zu senden in einer Schleife.

Wenn ich einen Empfänger manuell stoppe, wird eine Ausnahme über unterbrochene Leitung geworfen und richtig behandelt. Aber manchmal Rohrbruch geschieht (Ursache für schlechte Verbindung nehme ich an) und die Ausnahme wie durch ein Wunder fällt durch alle Fänge und die Anwendung beendet wird:

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' 

Untersuchung der Kern sehe ich, dass es in boost passiert :: asio :: Schreiben entstand in io_service :: run(). Was mache ich falsch?

Ich habe auch versucht, den TCP-Server mit async_write neu schreiben, aber es passiert immer noch, aber nicht so oft.

EDIT1: wenn ich den Empfänger manuell stoppe, um gebrochenes Rohr zu verursachen, bekomme ich die genau selbe Ausnahme und den genau gleichen Callstack aber dieses kann ich behandeln.

EDIT2: von dem, was ich jetzt verstehe, kann nicht-abfangbare Ausnahme das Ergebnis von zu vielen Daten sein, die zu schnell durch den Sockel gesendet werden. Nicht sicher, obwohl.

Answer 1

Die Fehlermeldung in terminate erklärt tatsächlich, was passiert. boost::exception_detail::clone_impl schlägt fehl. Ohne den Code zu durchforsten, würde ich annehmen, dass er verwendet wird, um den Kopierkonstruktor der Ausnahmeklasse zu implementieren. Wenn dieser Kopierkonstruktor während der Ausnahmebehandlung eine Ausnahmebedingung auslöst, wird der Ausnahmeblock umgangen und die Ausnahme wird nach oben weitergegeben. (Auch wenn Sie durch Verweis fangen, können Kopien vom Compiler noch hergestellt werden.)

Jetzt weiß ich nicht warum der Kopierkonstruktor fehlschlägt; Es gibt nicht genug in der Frage zu wissen. Aber this question in Bezug auf asynchrone E/A hatte ein sehr ähnliches Problem, und dort scheint die Crux gewesen zu sein, dass ein shared_ptr vor der Verarbeitung der Ausnahme zerstört wurde. Sieht ähnlich aus.