nullptr access in `kqueue_reactor::deregister_descriptor`

[timblechmann]

unfortunately i haven't been able to find a reduced test case, but in rare cases i'm seeing a nullptr dereference in kqueue_reactor::deregister_descriptor:

[2022-04-28T02:14:50.371Z] /Volumes/build/NIBuild/3rdparty/boost-v1.78.0-R6/boost/asio/detail/impl/kqueue_reactor.ipp:327:25: runtime error: member access within null pointer of type 'boost::asio::detail::kqueue_reactor::descriptor_state'
[2022-04-28T02:14:50.371Z] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Volumes/build/NIBuild/3rdparty/boost-v1.78.0-R6/boost/asio/detail/impl/kqueue_reactor.ipp:327:25 in 
[2022-04-28T02:14:50.371Z] UndefinedBehaviorSanitizer:DEADLYSIGNAL
[2022-04-28T02:14:50.371Z] ==27207==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000100f851d0 (pc 0x00010110d8a5 bp 0x7ffeef223680 sp 0x7ffeef2235d0 T27514402)
[2022-04-28T02:14:50.371Z] ==27207==The signal is caused by a READ memory access.
[2022-04-28T02:14:50.371Z]     #0 0x10110d8a5 in boost::asio::detail::kqueue_reactor::deregister_descriptor(int, boost::asio::detail::kqueue_reactor::descriptor_state*&, bool) kqueue_reactor.ipp:327
[2022-04-28T02:14:50.371Z]     #1 0x1011103c3 in boost::asio::detail::reactive_socket_service_base::close(boost::asio::detail::reactive_socket_service_base::base_implementation_type&, boost::system::error_code&) reactive_socket_service_base.ipp:109
[2022-04-28T02:14:50.371Z]     #2 0x101008e89 in boost::asio::basic_socket<boost::asio::local::stream_protocol, boost::asio::any_io_executor>::close(boost::system::error_code&) basic_socket.hpp:543
[2022-04-28T02:14:50.371Z]     #3 0x101008a0e in ni::msgpack_rpc::unix_domain_sockets::rpc_client::disconnect() rpc_client_unix_domain_sockets.cpp:60
[2022-04-28T02:14:50.371Z]     #4 0x1010087d3 in ni::msgpack_rpc::unix_domain_sockets::rpc_client::handle_connection_ended(boost::system::error_code const&) rpc_client_unix_domain_sockets.cpp:88
[2022-04-28T02:14:50.371Z]     #5 0x10100df67 in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, ni::msgpack_rpc::unix_domain_sockets::socket_helper::start_async_receive_size()::$_0, boost::asio::any_io_executor>::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) reactive_socket_recv_op.hpp:145

the code in question is:

void kqueue_reactor::deregister_descriptor(socket_type descriptor,
    kqueue_reactor::per_descriptor_data& descriptor_data, bool closing)
{
  if (!descriptor_data)
    return;

  mutex::scoped_lock descriptor_lock(descriptor_data->mutex_);

  if (!descriptor_data->shutdown_) // here the nullptr access occurs

oddly enough, there is a nullptr check two lines before, so i suspect a race condition, though i wonder if it is somehow related to #641