Description

eturner303

opened on Feb 20, 2019

Issue body actions

Greetings! I'm seeing a segmentation fault when attempting to use the following code on a HTTPS URL that is returning a "connection refused" error.

GDB RESULTS:
terminate called after throwing an instance of 'boost::exception_detail::clone_implboost::system::system_error'
what(): Connection refused
[New Thread 0x7ffedeffd700 (LWP 30879)]

(gdb) bt
#0 0x00007fffe8f85428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007fffe8f8702a in __GI_abort () at abort.c:89
#2 0x00007fffe98c884d in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007fffe98c66b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007fffe98c6701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007fffe98f1d38 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffe9bc26ba in start_thread (arg=0x7ffef4ff9700) at pthread_create.c:333
#7 0x00007fffe905741d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

SAMPLE CODE:
boost::network::http::client::response l_httpResponse;

        try
        {
          boost::network::http::client l_httpClient;

          std::string l_url = "http://127.0.0.1:9001/" // make sure this returns connection refused on a telnet attempt

          boost::network::http::client::request l_httpRequest(l_url);

          l_httpResponse = l_httpClient.get(l_httpRequest);

          l_success = true;
        }
        catch (...)
        {
          l_success = false;
        }

Activity

1. deanberris commented on Feb 20, 2019

   

   deanberris

   on Feb 20, 2019

   Member

   More actions

   Does it go away if you move the client object l_httpClient outside of the try block?
2. eturner303 commented on Feb 20, 2019

   

   eturner303

   on Feb 20, 2019

   Author

   More actions

   Hi! Regarding your question: The crash does not go away if the client is moved ouside of the try block. I also tried keeping the Client around eternally (never destroying it) and this did not work either.

   One thing I noticed:

   • on connection refused, the exception is not forwarded back into this thread from cpp-netlib. Meaning, the code successfully exits the try block, never triggering the catch block. This seems wrong, yes? How would one detect a 'connection refused' error without using a try/catch on this operation?

   Also:

   • The terminal output from the crash is:

   terminate called after throwing an instance of 'boost::exception_detail::clone_implboost::system::system_error'
   what(): Connection refused
   Aborted (core dumped)

   And:

   • Switching from ::client to ::basic_client<boost::network::http::tags::http_default_8bit_udp_resolve, 1, 1> does not change the behavior (it also crashes, despite being synchronous). This is true both inside and outside the try block. Also, the synchronous client passes the try block (not triggering catch) on connection refused error.

   Thanks for any advice or information
3. eturner303 commented on Feb 20, 2019

   

   eturner303

   on Feb 20, 2019

   Author

   More actions

   I have found a temporary workaround for this issue:

   • accessing l_httpResponse.status() from within the try () block successfully throws an exception in a connection_refused state, allowing this crash to be avoided.

   It seems if you do not access the http response from within the try block, it will exit the block without throwing exceptions in a connection_refused case -- but accessing status() triggers the exception.
4. igorpeshansky commented on Feb 20, 2019

   

   igorpeshansky

   on Feb 20, 2019

   More actions

   This seems WAI. get() is lazy, so the actual connection happens when you access any part of the response.

   [Edit] Didn't notice that it's also happening for a synchronous client. @deanberris, are those still supported?
5. deanberris commented on Feb 21, 2019

   

   deanberris

   on Feb 21, 2019

   Member

   More actions

   There's no more synchronous client since 0.12.x if I recall correctly.

Issue actions