Segfault when calling IMasterSession.BeginShutdown and already shutdown

[sidhoda]

Calling BeginShutdown on IMasterSession object will result in an segfault / access violation if the session has already been shutdown.

An example of where this can happen is if the master is in the process of proactively shutting down the session and the connection is dropped by the remote end.

Example stack trace when this happens:

STACK_TEXT:  
06b8faf8 69ec141c 06b8fb14 aafcb124 ffffffff DNP3CLRAdapter!std::enable_shared_from_this<asiodnp3::LinkSession>::shared_from_this+0x20
06b8fb64 69ed4320 06b8fb94 06b8fb94 aafcb1e8 DNP3CLRAdapter!asiodnp3::LinkSession::Shutdown+0x3c
06b8fba8 69ed7c1b 0499d608 0f116af0 06b8fc20 DNP3CLRAdapter!asio::detail::completion_handler<<lambda_5fcb07ee93ffcad8cc2f6041bdfd959e> >::do_complete+0xb0
06b8fbf0 69ed8f4d 0499d608 0f09ae10 06b8fc20 DNP3CLRAdapter!asio::detail::strand_service::do_complete+0x9b
06b8fc50 69ed91b5 0499d608 06b8fca0 aafcb6cc DNP3CLRAdapter!asio::detail::win_iocp_io_service::do_one+0x1ed
06b8fc8c 69ed8896 06b8fca0 059be800 04946310 DNP3CLRAdapter!asio::detail::win_iocp_io_service::run+0xc5
06b8fd24 69ed8c48 00000003 aafcb70c 049420c0 DNP3CLRAdapter!asiopal::ThreadPool::Run+0x96
06b8fd4c 69ed8a76 059be800 69ed8a1a 06b8fd98 DNP3CLRAdapter!std::_LaunchPad<std::unique_ptr<std::tuple<<lambda_0047fcd682f973a49a6c77c568ae3e72> >,std::default_delete<std::tuple<<lambda_0047fcd682f973a49a6c77c568ae3e72> > > > >::_Run+0x88
06b8fd5c 6965da5f 059be800 aa4cb6f1 6965da20 DNP3CLRAdapter!std::_LaunchPad<std::unique_ptr<std::tuple<<lambda_0047fcd682f973a49a6c77c568ae3e72> >,std::default_delete<std::tuple<<lambda_0047fcd682f973a49a6c77c568ae3e72> > > > >::_Go+0x6
06b8fd98 74c37c04 049420c0 74c37be0 ba51669c ucrtbase!_o__CIpow+0x4f
06b8fdac 76ffad8f 049420c0 b9897e35 00000000 kernel32!BaseThreadInitThunk+0x24
06b8fdf4 76ffad5a ffffffff 76fe00ac 00000000 ntdll!__RtlUserThreadStart+0x2f
06b8fe04 00000000 6965da20 049420c0 00000000 ntdll!_RtlUserThreadStart+0x1b

[emgre]

Thanks for the report, I redid your PR with an extra check in MasterSessionStack and a test case to reproduce the issue.