http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> --- (It would be easier to make sense of this if the line numbers in your gdb and valgrind output matched the code on github.) Blocking in pthread_once could be a symptom of using an invalid pthread_once_t that has already been destroyed, and the valgrind output indeed shows that the set_value() call is being made on a shared state that has been deleted already, when the promise that owned it went out of scope. It looks like that shouldn't have happened though. Is it possible the task is getting run twice by the thread pool, so on the second run the reference to the promise is dangling? When the process hangs could you use gdb to print &promise in both threads, where it is waiting on future::get and promise::set_value? The values should be the same, since the closure running in the thread pool should have a reference to the local object in the waiting thread. Replacing the lambda in the destructor with a call to a member function would help to rule out a code generation problem due to the lambda, which is a remote possibility. Can the problem be reproduced by one of the unit tests in the httpp repo? N.B. the std::move in Manager::cancelConnection is redundant, the return value from cancel_connection is already an rvalue.
