Boost C++ Libraries: Ticket #8795: async_connect incorrectly reports success on failure

stephen.pope@… — Tue, 16 Jul 2013 17:59:47 GMT

Upgrading my own code to use 1.54.0 instead of 1.53.0, I also encountered this same problem. It appears to be due to the refactoring of the socket_ops::non_blocking_connect() function, which now calls socket_ops::connect() and then (unless getting back boost::asio::error::already_started), calls socket_ops::getsockopt with SO_ERROR. The problem is that the call to ::connect() within socket_ops::connect() has already effectively cleared the error (and set errno appropriately), and ec already contains the desired error code, so the call to getsockopt ends up clearing the error information from ec, making it appear to have succeeded.

Unfortunately I am not familiar enough with the intent of the changes to propose the correct solution, although I suspect it would be to only call socket_ops::getsockopt() if the call to socket_ops::connect() did not itself return an error.

naidu.trk@… — Wed, 17 Jul 2013 12:11:33 GMT

I encountered this while working with websocketpp library which uses boost asio. connect returns success despite the failure to connect. websocketpp returns the same success to the application.

anonymous — Thu, 18 Jul 2013 07:03:25 GMT

I also have same problem with boost 1.54.0. The error code from async_connect()'s callback is always success in spite of connection failed.

junk@… — Tue, 30 Jul 2013 20:25:59 GMT

I have the same problem. I created a workaround in my code by calling connect and then posting the response to the async_connect handle. This, of course, blocks the calling thread :(.

Fri, 02 Aug 2013 09:42:23 GMT

Confirmed also in boost trunk as of 20130801 (1.55) linux ubuntu saucy 64 bits. A regression that is causing services that are supposed to reconnect on failure to proceed.

Quite easy to reproduce using the async_client in the examples without any listening http server. Add a debug trace (should get connection refused):

root@pookie:/tmp# g++ -c -o client.o client.cpp
root@pookie:/tmp# g++ -o client client.o -lboost_system -lboost_thread -lpthread
root@pookie:/tmp# ./client localhost /index.html
handle_connect Error: system:0
Error: Broken pipe

Thanks R.

jft@… — Wed, 14 Aug 2013 20:02:31 GMT

You cannot even use boost::asio::ip::tcp::iostream because the connect method makes use of async_connect. I would consider this a huge bug and I am surprised there are only a few responses to this ticket. I spend a considerable amount of time debugging my projects today to find this bug (I use Arch Linux and they updated recently).

anonymous — Thu, 15 Aug 2013 20:38:16 GMT

For my own use, I found that simply inserting:

if (ec) return true;

at line 524 of boost/asio/detail/impl/socket_ops.ipp (i.e. in non_blocking_connect() after the check for error::already_started and before calling getsockopt()) has proven to be a reasonable workaround. Again, as I do not understand the intent of the changes from 1.53.0, I am not sure that this is the correct bugfix, so YMMV.

mvd — Fri, 16 Aug 2013 09:22:13 GMT

I confirm the bug in BOOST 1.54. The connect handler reports success although the connect attempt failed.

david.keegan@… — Fri, 23 Aug 2013 15:37:35 GMT

Yes, I've hit this problem too on Linux.

anonymous — Mon, 26 Aug 2013 15:17:55 GMT

I confirm the problem in 1.54.0 boost.

anonymous — Tue, 27 Aug 2013 23:05:51 GMT

On CentOS 6.4 (64bit), upgrade from 1.49.0 to 1.54.0 introduced this issue for me. The error code in connect handler reports success and the socket appears to be is_open().

summary changed

anonymous — Wed, 28 Aug 2013 12:50:46 GMT

summary async_connect oncorrectly reports success on failure → async_connect incorrectly reports success on failure

Sat, 31 Aug 2013 15:29:34 GMT

Confirmed on Slackware64, using boost 1.54.0

agazso@… — Tue, 10 Sep 2013 13:33:10 GMT

For me this fix worked

if (ec == asio::error::connection_refused) return true;

at line 524 of boost/asio/detail/impl/socket_ops.ipp

It seems that when connect returns ECONNREFUSED then getsockopt returns no error.

status changed; resolution set

chris_kohlhoff — Tue, 01 Oct 2013 10:44:56 GMT

status new → closed
resolution → fixed

Minimal fix on trunk in [85738]. Subsequent cleanup in [85739]. Merged to release in [85838].

anonymous — Tue, 18 Nov 2014 16:55:08 GMT

With Boost 1.55 running on Windows 8.1 I was seeing a single false connection. On Boost 1.56 I see repeated false connections, over and over again.

By "false connections" I mean that the connect handler for async_connect gets called right away (when the other end of the socket is not there), with error_code zero and where conn->socket.is_open() return true. Stepping into the boost code I see in win_iocp_io_service.ipp line 405 result_ec is 10057 (WSAENOTCONN). The next line of code (ec = boost::system::error_code();) sets ec to zero.

Does anyone else see this?

anonymous — Wed, 13 Apr 2016 21:22:10 GMT

I am experiencing this bug using MSVC 14 and Boost 1.60.

No asynchronous solution in sight. Finnicky.

anonymous — Wed, 13 Apr 2016 22:06:30 GMT

Replying to anonymous:

I am experiencing this bug using MSVC 14 and Boost 1.60.

No asynchronous solution in sight. Finnicky.

UPDATE: Replacing asio::ip::tcp::acceptor.cancel() with asio::ip::tcp::acceptor.close() in another thread, fixes some oddity within a shared asio::io_service...

anonymous — Wed, 05 Apr 2017 10:01:16 GMT

Boost 1.63.0, Windows 10 64-bit.

Also shows no error despite the connection failed.

status, version changed; resolution deleted

anonymous — Thu, 06 Apr 2017 06:11:17 GMT

status closed → reopened
version Boost 1.54.0 → Boost 1.63.0
resolution fixed

status changed; resolution deleted

anonymous — Thu, 06 Apr 2017 06:11:19 GMT

status closed → reopened
resolution fixed

anonymous — Fri, 04 Aug 2017 08:25:12 GMT

Boost 1.59 Win64 has the same issue!