Stable crash in client when server disconnects

[oleevg]

Environment:
Client side - cpprestsdk 2.10.11( and also 2.10.13) Linux static build with gcc4.8, boost 1.68.0 Linux static build with gcc4.8.
Server side - python script based on http.server module (the problem occurs only when http.server.HTTPServer is used, but not http.server.ThreadingHTTPServer).

The client is C++ executable that periodically is sending requests to the server. When the server is stopped the client application crashes because of unhandled exception:

  what():  uninitialized stream object

backtrace:

(gdb) bt
#0  0x00007ffff6c065f7 in raise () from /lib64/libc.so.6
#1  0x00007ffff6c07ce8 in abort () from /lib64/libc.so.6
#2  0x00007ffff750b9d5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
#3  0x00007ffff7509946 in ?? () from /lib64/libstdc++.so.6
#4  0x00007ffff7508909 in ?? () from /lib64/libstdc++.so.6
#5  0x00007ffff7509574 in __gxx_personality_v0 () from /lib64/libstdc++.so.6
#6  0x00007ffff6fa2903 in ?? () from /lib64/libgcc_s.so.1
#7  0x00007ffff6fa2e37 in _Unwind_Resume () from /lib64/libgcc_s.so.1
#8  0x00000000007045c4 in boost::asio::detail::scheduler::run (this=0x10fc110, ec=...) at /srv/build/agent/work/21711c7319e2844b/boost.lin.gcc48.rt-static.x86_64.1.68.0.3/include/boost/asio/detail/impl/scheduler.ipp:157
#9  0x0000000000705055 in boost::asio::io_context::run (this=0x10f1748 <crossplat::threadpool::shared_instance()::s_shared+8>)
    at /srv/build/agent/work/21711c7319e2844b/boost.lin.gcc48.rt-static.x86_64.1.68.0.3/include/boost/asio/impl/io_context.ipp:62
#10 0x0000000000821b29 in (anonymous namespace)::threadpool_impl::thread_start (arg=0x10f1740 <crossplat::threadpool::shared_instance()::s_shared>) at /srv/build/agent/work/21711c7319e2844b/cpprestsdk/cpprest/src/pplx/threadpool.cpp:63
#11 0x0000000000821a5d in (anonymous namespace)::threadpool_impl::__lambda134::operator() (__closure=0x10ff5b8) at /srv/build/agent/work/21711c7319e2844b/cpprestsdk/cpprest/src/pplx/threadpool.cpp:45
#12 0x000000000082213c in boost::asio::detail::posix_thread::func<(anonymous namespace)::threadpool_impl::add_thread()::__lambda134>::run(void) (this=0x10ff5b0)
    at /srv/build/agent/work/21711c7319e2844b/boost.lin.gcc48.rt-static.x86_64.1.68.0.3/include/boost/asio/detail/posix_thread.hpp:86
#13 0x0000000000704d24 in boost::asio::detail::boost_asio_detail_posix_thread_function (arg=0x10ff5b0)
    at /srv/build/agent/work/21711c7319e2844b/boost.lin.gcc48.rt-static.x86_64.1.68.0.3/include/boost/asio/detail/impl/posix_thread.ipp:74
#14 0x00007ffff7bc6dc5 in start_thread () from /lib64/libpthread.so.0
#15 0x00007ffff6cc7ced in clone () from /lib64/libc.so.6

The only place I have found where such exception might be thrown is in the file: cpprestsdk/include/cpprest/streams.h.

Possibly related to #979, but this fix is included in 2.10.11 (2.10.13) versions that I tried.

Thanks!

[reneme]

Can you provide the python server example you are using? I would like to try and reproduce that.

[oleevg]

Hi!

The python server is based on https://gist.github.com/iaverin/f81720df9ed37a49ecee6341e4d5c0c6 with minor changes. The only significant change is moving to explicit HTTP/1.1 using.
rest_server.zip

[reneme]

I am in the process of setting up a tiny project to be able to play with this a little. Your problem actually sounds a lot like the problem that was fixed in this pull request. This addressed an issue with reusing connections that were closed by the server in the mean time.

Can you have a quick look at the code I linked above, whether this client.cpp is roughly what you are doing?

[reneme]

... so far no luck with reproducing your issue, unfortuantely. Though, I'm also using a different compiler and I am on macOS. If it would be a reproducible bug in cpprest's request handling, I would assume that it would show up anyway.

[oleevg]

I performed some investigation and found a bug in our scheme of cpprestsdk package versioning. Actually we are using cpprestsdk 2.10.6. And that version doesn't include the fix #979.

It was my mistake and I am closing the issue. Thank you a lot for the help!