Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash with client::get on connection refused #870

Open
eturner303 opened this issue Feb 20, 2019 · 5 comments
Open

Crash with client::get on connection refused #870

eturner303 opened this issue Feb 20, 2019 · 5 comments

Comments

@eturner303
Copy link

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;
        }
@deanberris
Copy link
Member

Does it go away if you move the client object l_httpClient outside of the try block?

@eturner303
Copy link
Author

eturner303 commented Feb 20, 2019

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

@eturner303
Copy link
Author

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.

@igorpeshansky
Copy link

igorpeshansky commented Feb 20, 2019

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?

@deanberris
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants