This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/60966] std::call_once sometime hangs
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 25 Apr 2014 17:53:21 +0000
- Subject: [Bug libstdc++/60966] std::call_once sometime hangs
- Auto-submitted: auto-generated
- References: <bug-60966-4 at http dot gcc dot gnu dot org/bugzilla/>
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.