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
