Hello,
It seems we are also experiencing this issue but with the beast frontend. We were using ceph v13.2.x before upgrading to v14.2.1 and then v14.2.2 a few weeks ago. We didn't have any problems with the v13.2.x release line but we only started noticing this issue when our load increased on the cluster.
Here's a gdb stacktrace at where the process is when attaching multiple times:
(gdb) bt
#0 0x000055ca3f3e9ff3 in get_obj_data::flush(rgw::OwningList<rgw::AioResultEntry>&&) ()
#1 0x000055ca3f3baacc in RGWRados::get_obj_iterate_cb(rgw_raw_obj const&, long, long, long, bool, RGWObjState*, void*) ()
#2 0x000055ca3f3bac84 in _get_obj_iterate_cb(rgw_raw_obj const&, long, long, long, bool, RGWObjState*, void*) ()
#3 0x000055ca3f3cdab1 in RGWRados::iterate_obj(RGWObjectCtx&, RGWBucketInfo const&, rgw_obj const&, long, long, unsigned long, int (*)(rgw_raw_obj const&, long, long, long, bool, RGWObjState*, void*), void*) ()
#4 0x000055ca3f3d1088 in RGWRados::Object::Read::iterate(long, long, RGWGetDataCB*) ()
#5 0x000055ca3f35aefc in RGWGetObj::execute() ()
#6 0x000055ca3f12842b in rgw_process_authenticated(RGWHandler_REST*, RGWOp*&, RGWRequest*, req_state*, bool) ()
#7 0x000055ca3f12ae14 in process_request(RGWRados*, RGWREST*, RGWRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, rgw::auth::StrategyRegistry const&, RGWRestfulIO*, OpsLogSocket*, optional_yield, rgw::dmclock::Scheduler*, int*) ()
#8 0x000055ca3f0888ba in void (anonymous namespace)::handle_connection<boost::asio::basic_stream_socket<boost::asio::ip::tcp> >(RGWProcessEnv&, boost::asio::basic_stream_socket<boost::asio::ip::tcp>&, boost::beast::basic_flat_buffer<std::allocator<char> >&, bool, ceph::async::SharedMutex<boost::asio::io_context::executor_type>&, rgw::dmclock::Scheduler*, boost::system::error_code&, boost::asio::basic_yield_context<boost::asio::executor_binder<void (*)(), boost::asio::executor> >) [clone .constprop.4035] ()
#9 0x000055ca3f089523 in void boost::coroutines::detail::trampoline_push_void<boost::coroutines::detail::push_coroutine_object<boost::coroutines::pull_coroutine<void>, void, boost::asio::detail::coro_entry_point<boost::asio::executor_binder<void (*)(), boost::asio::strand<boost::asio::io_context::executor_type> >, (anonymous namespace)::AsioFrontend::accept((anonymous namespace)::AsioFrontend::Listener&, boost::system::error_code)::{lambda(boost::asio::basic_yield_context<boost::asio::executor_binder<void (*)(), boost::asio::executor> >)#3}>&, boost::coroutines::basic_standard_stack_allocator<boost::coroutines::stack_traits> > >(boost::context::detail::transfer_t) ()
#10 0x00007f97b77821ef in make_fcontext () from target:/usr/x86_64-pc-linux-gnu/lib/libboost_context.so.1.69.0
#11 0x000055ca3f758d10 in vtable for boost::coroutines::detail::push_coroutine_object<boost::coroutines::pull_coroutine<void>, void, boost::asio::detail::coro_entry_point<boost::asio::executor_binder<void (*)(), boost::asio::strand<boost::asio::io_context::executor_type> >, (anonymous namespace)::AsioFrontend::accept((anonymous namespace)::AsioFrontend::Listener&, boost::system::error_code)::{lambda(boost::asio::basic_yield_context<boost::asio::executor_binder<void (*)(), boost::asio::executor> >)#3}>&, boost::coroutines::basic_standard_stack_allocator<boost::coroutines::stack_traits> > ()
#12 0x00007f9700000026 in ?? ()
#13 0x0000000000000000 in ?? ()
When strace'ing that process, it doesn't log anything.
We may have the same crash issues as described in https://tracker.ceph.com/issues/39660 but I don't have a useful coredump with a stacktrace yet, I'll try to get one.
Each time it happens we restart the radosgw process to resolve the issue.
Let me know if I can get you anything else useful.