[Bug libstdc++/60966] std::call_once sometime hangs

["thomas.sanchz at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966

--- Comment #2 from Thomas Sanchez <thomas.sanchz at gmail dot com> ---
Hi,

Thanks for your answer,
(In reply to Jonathan Wakely from comment #1)
> (It would be easier to make sense of this if the line numbers in your gdb
> and valgrind output matched the code on github.)
> 
Indeed, sorry, I added some debug that I did not commit, I'll create a branch
with this version tomorrow. The important things is that it is always on
set_value() that I hang.


> 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.
> 

I reached the same conclusion.

> 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?
Hum, since I'm using boost::asio (boost::asio::io_service::post/dispatch), I do
hope that this is not the case, but this is something I can check. I don't
remember however having a double log.

> 
> 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.

Will do.

> 
> 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.
> 

Will do.

> Can the problem be reproduced by one of the unit tests in the httpp repo?
> 

Unfortunately I don't have anything to reproduce the bug each time.
I'll try something tomorrow.

> 
> N.B. the std::move in Manager::cancelConnection is redundant, the return
> value from cancel_connection is already an rvalue.

Yes, I know, the problem is I have some hard time to avoid doing this as it is
more for me and what I expect the compiler to do or the semantics I want the
code to have :)