It does not always come from quite the same place, but it's always
a EBADF on the socket AFAICT. This suggests a race somewhere, but
for now it's better to fail than hang.
#0 __cxxabiv1::__cxa_throw (obj=0x7e5c6c07bd30, tinfo=0x651167ae8770 <typeinfo for boost::wrapexcept<boost::system::system_error>>,
dest=0x651165bb4010 <boost::wrapexcept<boost::system::system_error>::~wrapexcept()>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:80
#1 0x00006511667b3d0c in __wrap___cxa_throw ()
#2 0x0000651165a423f1 in void boost::throw_exception<boost::system::system_error>(boost::system::system_error const&, boost::source_location const&) ()
#3 0x0000651165bc1e49 in boost::asio::detail::do_throw_error(boost::system::error_code const&, char const*, boost::source_location const&) ()
#4 0x0000651165bcd107 in epee::net_utils::connection<epee::net_utils::http::http_custom_handler<epee::net_utils::connection_context_base> >::save_dbg_log() ()
#5 0x0000651165c4a1aa in epee::net_utils::boosted_tcp_server<epee::net_utils::http::http_custom_handler<epee::net_utils::connection_context_base> >::handle_accept(boost::system::error_code const&, bool) ()
#6 0x0000651165bd7250 in boost::asio::detail::reactive_socket_accept_op<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::any_io_executor>, boost::asio::ip::tcp, boost::_bi::bind_t<void, boost::_mfi::mf1<void, epee::net_utils::boosted_tcp_server<epee::net_utils::http::http_custom_handler<epee::net_utils::connection_context_base> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<epee::net_utils::boosted_tcp_server<epee::net_utils::http::http_custom_handler<epee::net_utils::connection_context_base> >*>, boost::arg<1> (*)()> >, boost::asio::any_io_executor>::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) ()
#7 0x0000651165b9cf53 in boost::asio::detail::scheduler::run(boost::system::error_code&) [clone .isra.0] ()
#8 0x0000651165bc8b73 in epee::net_utils::boosted_tcp_server<epee::net_utils::http::http_custom_handler<epee::net_utils::connection_context_base> >::worker_thread() ()
#9 0x0000651167157fe7 in thread_proxy ()
#10 0x00007e5cfd4b44c0 in start_thread () from /lib64/libpthread.so.0
#11 0x00007e5cfd3e2133 in clone () from /lib64/libc.so.6
Relevant commits on the old cleanup PR:
36933c7f5c7778e2d7fbfea5361c11fb41070467
21e43de0f300ee47b7e597098908601bf591950b
3c678bb1cedfd7b865ac2e7aaf014de4bfb3eb3d
Actions:
1. Remove unused functions from misc_os_dependent.h
2. Move three remaining functions, get_gmt_time, get_ns_count, and get_tick_count into time_helper.h
3. Remove unused functions from time_helper.h
4. Refactor get_ns_count and get_internet_time_str and get_time_interval_string
5. Remove/add includes as needed
Relevant commits on the old PR:
a9fbe52b02ffab451e90c977459fea4642731cd1
9a59b131c4ed1be8afe238fff3780fe203c65a46
7fa9e2817df9b9ef3f0290f7f86357939829e588
Here lies dozens of unused files. This commit is ONLY file deletions except
for the removing of a couple of #includes and removing filenames from CmakeLists
where appropriate.
In this repo, `boost::interprocess` was being used soley to make `uint32_t` operations atomic. So I replaced each instance of
`boost::interprocess::ipcdetail::atomic(...)32` with `std::atomic` methods. I replaced member declarations as applicable. For example,
when I needed to change a `volatile uint32_t` into a `std::atomic<uint32_t>`. Sometimes, a member was being used a boolean flag, so
I replaced it with `std::atomic<bool>`.
You may notice that I didn't touch `levin_client_async.h`. That is because this file is entirely unused and will be deleted in PR monero-project#8211.
Additional changes from review:
* Make some local variables const
* Change postfix operators to prefix operators where value was not need
