Repository navigation
Client destructor hangs in 64-bit C++11 mode #232
Description
When I compile the following program asa 64-bit program in C++11 mode, and run it:
#include <boost/network/protocol/http/client.hpp>
int main(int argc, char** argv)
{
using namespace boost::network;
using namespace boost::network::http;
std::string result = body(client().get(client::request("http://www.boost.org/")));
}the program hangs. The stack trace is the following:
#0 0x00007ffff72d785c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1 0x000000000045d973 in boost::thread::join() ()
#2 0x000000000042be15 in boost::network::http::impl::async_client<boost::network::http::tags::http_async_8bit_udp_resolve, 1u, 1u>::~async_client (this=0x8002f0,
__in_chrg=<optimized out>) at cpp-netlib/boost/network/protocol/http/client/async_impl.hpp:73
#3 0x000000000042fd6c in boost::network::http::basic_client_impl<boost::network::http::tags::http_async_8bit_udp_resolve, 1u, 1u>::~basic_client_impl (this=0x8002f0,
__in_chrg=<optimized out>) at cpp-netlib/boost/network/protocol/http/client/pimpl.hpp:79
#4 0x000000000042e5fb in boost::checked_delete<boost::network::http::basic_client_impl<boost::network::http::tags::http_async_8bit_udp_resolve, 1u, 1u> > (x=0x8002f0)
at boost/boost/checked_delete.hpp:34
#5 0x000000000043fa0c in boost::detail::sp_counted_impl_p<boost::network::http::basic_client_impl<boost::network::http::tags::http_async_8bit_udp_resolve, 1u, 1u> >::dispose (
this=0x801150) at boost/boost/smart_ptr/detail/sp_counted_impl.hpp:78
#6 0x000000000040d974 in boost::detail::sp_counted_base::release (this=0x801150) at boost/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145
#7 0x000000000040da37 in boost::detail::shared_count::~shared_count (this=0x7fffffffdc28, __in_chrg=<optimized out>)
at boost/boost/smart_ptr/detail/shared_count.hpp:305
#8 0x0000000000415d70 in boost::shared_ptr<boost::network::http::basic_client_impl<boost::network::http::tags::http_async_8bit_udp_resolve, 1u, 1u> >::~shared_ptr (this=0x7fffffffdc20,
__in_chrg=<optimized out>) at boost/boost/smart_ptr/shared_ptr.hpp:164
#9 0x0000000000415d8a in boost::network::http::basic_client_facade<boost::network::http::tags::http_async_8bit_udp_resolve, 1u, 1u>::~basic_client_facade (this=0x7fffffffdc20,
__in_chrg=<optimized out>) at cpp-netlib/boost/network/protocol/http/client/facade.hpp:23
#10 0x0000000000415da4 in boost::network::http::basic_client<boost::network::http::tags::http_async_8bit_udp_resolve, 1u, 1u>::~basic_client (this=0x7fffffffdc20,
__in_chrg=<optimized out>) at cpp-netlib/boost/network/protocol/http/client.hpp:33
#11 0x000000000040c78c in main (argc=1, argv=0x7fffffffdd28) at test.cpp:8
Interestingly, if I build the program in 32-bit mode, or without the C++11 flag, it works fine.
This happens regardless of whether boost and cpp-netlib are also built in C++11 mode.
Some more information:
compiler: gcc 4.8
OS: Ubuntu 10.04
boost version: I tried with both 1.51 and trunk
cpp-netlib version: 0.9.4
I have the strangest feeling that I've encountered this issue before, and solved it, but I cannot for the life of me remember how.
Any ideas?
Activity
deanberris commentedon Apr 26, 2013
Interesting. I wouldn't think this is a bug with cpp-netlib though -- how are you building things and making sure your binaries are 32-bit/64-bit? Reproduction steps would be nice.
One thing to note is that 0.9.4 does not play nicely with C++11 so you will be encountering weirdness if you do that.
HighCommander4 commentedon Apr 26, 2013
I build boost with
./bjam variant=release link=static runtime-link=static threading=multi toolset=gcc cxxflags=<flags> install, and cpp-netlib withCXXFLAGS=<flags> cmake ., where<flags>includes or does not include-m32and-std=c++11depending on the configuration I want to build.I see. Is there a version that plays nicely with C++11? My program uses C++11 features extensively, so I can't build in C++03 mode.
deanberris commentedon Apr 26, 2013
Okay. I have a number of suggestions:
I would convert your code to:
HighCommander4 commentedon Apr 26, 2013
Hmm. I rebuilt boost and cpp-netlib, again, since the last time I tried it, and now it works fine. I honestly don't know what's changed...
Sorry for the noise.
CountJugula commentedon Apr 16, 2014
I ran into the same hang described by HighCommander4 with 0.11.0. I discovered that if my project used
-std=c++11in the compilation line then I needed to build cpp-netlib with the-std=c++11option as well to have the client not hang in the client destructor.Posting here as I wasn't able to find this solution (or problem) elsewhere online.
sebadoom commentedon May 8, 2014
@CountJugula Thanks for posting your findings, I was about to switch to straight libcurl after I run into the same issue. I can confirm compiling cpp-netlib in C++11 mode fixes the problem when linking with C++11-compiled code.
niklas88 commentedon Jul 14, 2015
I hit the same problem when trying to build a CMakeLists.txt for the twitter_search example (that by the way doesn't work anymore because of Twitter API changes) and starting with one with --std=c++11 in it. Also I'm using 0.11.1
It's fixed when building cpp-netlib with --std=c++11 too
deanberris commentedon Jul 16, 2015
@niklas88 Thanks for looking into this!
Change according to cpp-netlib/cpp-netlib#232. Prevents a deadlock fr…
Various changes to be able to build osquery on debian wheezy and debi…