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

[thomas.sanchz at gmail dot com]

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

--- Comment #5 from Thomas Sanchez <thomas.sanchz at gmail dot com> ---
With my previous mail, the link I added was because I wanted to ask that if you
were not able to reproduce the problem I could use CARE to recreate the
environment I'm running my test.

With lambda replaced (commit fd8b4a8ce7847dc561c937e2a3c80db0d735835c) the
seems to be triggered a bit less often however, I do have a segfault in
malloc_consolidate, I'll come back onto this later.

Manager.cpp:121
(gdb) print future
$1 = {
  <std::__basic_future<void>> = {
    <std::__future_base> = {<No data fields>}, 
    members of std::__basic_future<void>: 
    _M_state = std::shared_ptr (count 2, weak 0) 0x812468
  }, <No data fields>}
(gdb) print promise
$2 = {
  _M_future = std::shared_ptr (count 2, weak 0) 0x812468, 
  _M_storage = std::unique_ptr<std::__future_base::_Result<void>> containing
0x812780
}

Manager.cpp:87
(gdb) print promise
$3 = (std::promise<void> &) @0x7fffffffce40: {
  _M_future = std::shared_ptr (count 2, weak 0) 0x812468, 
  _M_storage = std::unique_ptr<std::__future_base::_Result<void>> containing
0x812780
}

This also seems ok.

About the segfault on the malloc, I think the problems are related, I guess it
is possible that the pthread_once does not always hangs and who knows what mess
it could cause in the memory.

In case you interested in the segfault, here is the trace:
Program received signal SIGSEGV, Segmentation fault.
malloc_consolidate (av=av@entry=0x7ffff722c760 <main_arena>) at malloc.c:4157
4157    malloc.c: No such file or directory.
(gdb) bt
#0  malloc_consolidate (av=av@entry=0x7ffff722c760 <main_arena>) at
malloc.c:4157
#1  0x00007ffff6eedc38 in _int_malloc (av=0x7ffff722c760 <main_arena>,
bytes=7288) at malloc.c:3423
#2  0x00007ffff6ef05f0 in __GI___libc_malloc (bytes=7288) at malloc.c:2891
#3  0x00007ffff7984d8f in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#4  0x00007ffff7984ecf in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5  0x00007ffff7985cbd in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6  0x0000000000506a08 in HTTPP::HTTP::client::detail::Manager::Manager
(this=0x811eb0, io=..., dispatch=...) at
/home/daedric/perso/httpp/src/httpp/http/client/Manager.cpp:52
#7  0x00000000004ef61b in HTTPP::HttpClient::HttpClient (this=0x7fffffffcfb0,
nb_thread=1, name="") at /home/daedric/perso/httpp/src/httpp/HttpClient.cpp:38

The segfault on the call of curl_multi_init and this one occurs in the
constructor. I was not able to check with valgrind so far if a failed
instanciation occurs after a trace about an invalid call_once/pthread_once