This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]