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.
Currently working on an EPEE [ser/de]ialization library for Rust and at first glance, EPEE seemed to have support for optional wrappers. However, after looking into it, this feature appears to be half-baked and unused. Furthermore, adding support for optional values would be better suited to implement at the storage level, in my opinion. That would make parsing DOMs easier and less error-prone. If anyone is currently using this code, please comment. Thanks!
At the time of writing, this PR has no merge conflicts with #8211
