Seen in Evergreen C Driver tests. Standalone MongoDBÂ v3.7.9-343-g6ab1592260 on Windows, the C Driver is built with TLS support from Microsoft's SChannel. It's attempting to send an isMaster command to test some details of the client's async SSL implementation. It crashes the server with:
2018-05-21T16:23:21.853+0000 I CONTROL [conn9] *** unhandled exception (access violation) at 0x000007FEFB9ECBA0, terminating 2018-05-21T16:23:21.853+0000 I CONTROL [conn9] *** access violation was a read from 0x0 2018-05-21T16:23:21.853+0000 I CONTROL [conn9] *** stack trace for unhandled exception: 2018-05-21T16:23:22.131+0000 I - [conn9] VCRUNTIME140.dll memcpy+0x336x mongod.exe ...\src\mongo\util\net\ssl\detail\impl\schannel.ipp(330) asio::ssl::detail::SSLHandshakeManager::doServerHandshake+0x589x mongod.exe ...\src\mongo\util\net\ssl\detail\impl\schannel.ipp(97) asio::ssl::detail::SSLHandshakeManager::nextHandshake+0x256x mongod.exe ...\src\mongo\util\net\ssl\detail\impl\engine_schannel.ipp(96) asio::ssl::detail::engine::handshake+0x52x mongod.exe ...\src\mongo\util\net\ssl\detail\buffered_handshake_op.hpp(63) asio::ssl::detail::buffered_handshake_op<asio::mutable_buffers_1>::process<asio::mutable_buffer const * __ptr64>+0x57x mongod.exe ...\src\mongo\util\net\ssl\detail\io.hpp(34) asio::ssl::detail::io<asio::basic_stream_socket<asio::generic::stream_protocol>,asio::ssl::detail::buffered_handshake_op<asio::mutable_buffers_1> >+0x96x mongod.exe ...\src\mongo\transport\session_asio.h(595) <lambda_f6f2e1bffb89ba5b7d46b59118d1310c>::operator()+0x112x mongod.exe ...\src\mongo\transport\session_asio.h(601) mongo::transport::TransportLayerASIO::ASIOSession::maybeHandshakeSSLForIngress<asio::mutable_buffers_1>+0x486x mongod.exe ...\src\mongo\transport\session_asio.h(388) <lambda_6ebb069d1bfd5721769cd5bb5f598637>::operator()+0x39x mongod.exe ...\src\mongo\util\future.h(103) mongo::future_details::callVoidOrStatus<<lambda_6ebb069d1bfd5721769cd5bb5f598637> & __ptr64>+0x31x mongod.exe ...\src\mongo\util\future.h(124) mongo::future_details::call<<lambda_6ebb069d1bfd5721769cd5bb5f598637> & __ptr64>+0x32x mongod.exe ...\src\mongo\util\future.h(194) mongo::future_details::throwingCall<<lambda_6ebb069d1bfd5721769cd5bb5f598637> & __ptr64,mongo::future_details::FakeVoid,mongo::future_details::Future<bool>,void>+0x26x mongod.exe ...\src\mongo\util\future.h(863) <lambda_3a26267831b8c0e29fc9fbe284e77d06>::operator()+0x59x mongod.exe ...\src\mongo\util\future.h(1067) mongo::future_details::Future<mongo::future_details::FakeVoid>::generalImpl<<lambda_3a26267831b8c0e29fc9fbe284e77d06>,<lambda_5f4bdc0e7c9c03f7610f77bb2780f4ea>,<lambda_4c2f342b8bbe34f98907388364936ebe> >+0x38x mongod.exe ...\src\mongo\util\future.h(859) mongo::future_details::Future<mongo::future_details::FakeVoid>::then<<lambda_6ebb069d1bfd5721769cd5bb5f598637>,mongo::future_details::Future<bool>,void,bool>+0x44x mongod.exe ...\src\mongo\util\future.h(1219) mongo::future_details::Future<void>::then<<lambda_6ebb069d1bfd5721769cd5bb5f598637> >+0x14x mongod.exe ...\src\mongo\transport\session_asio.h(385) mongo::transport::TransportLayerASIO::ASIOSession::read<asio::mutable_buffers_1>+0x256x mongod.exe ...\src\mongo\transport\session_asio.h(337) mongo::transport::TransportLayerASIO::ASIOSession::sourceMessageImpl+0x190x mongod.exe ...\src\mongo\transport\session_asio.h(131) mongo::transport::TransportLayerASIO::ASIOSession::sourceMessage+0x85x mongod.exe ...\src\mongo\transport\service_state_machine.cpp(247) <lambda_a9e5333abbb985a176b6aaeb009d3a08>::operator()+0x84x mongod.exe ...\src\mongo\transport\service_state_machine.cpp(254) mongo::ServiceStateMachine::_sourceMessage+0x174x mongod.exe ...\src\mongo\transport\service_state_machine.cpp(436) mongo::ServiceStateMachine::_runNextInGuard+0x242x mongod.exe ...\src\mongo\transport\service_state_machine.cpp(479) <lambda_b23af5efc3b61ab25bff0c3bcd13382b>::operator()+0x109x mongod.exe ...\src\mongo\transport\service_executor_synchronous.cpp(133) <lambda_472996f9e6b00ec91d31b43a6cde81f7>::operator()+0x217x mongod.exe c:\program files (x86)\microsoft visual studio 14.0\vc\include\thr\xthread(247) std::_LaunchPad<std::unique_ptr<std::tuple<std::function<void __cdecl(void)> >,std::default_delete<std::tuple<std::function<void __cdecl(void)> > > > >::_Run+0x133x mongod.exe c:\program files (x86)\microsoft visual studio 14.0\vc\include\thr\xthread(210) std::_Pad::_Call_func+0x9x ucrtbase.DLL crt_at_quick_exit+0x125x kernel32.dll BaseThreadInitThunk+0x13x 2018-05-21T16:23:22.131+0000 I CONTROL [conn9] writing minidump diagnostic file c:\mongodb\bin\mongod.2018-05-21T16-23-22.mdmp
The log file as attached. The minidump, unfortunately, is lost. The only notable thing about this test is that the client does not do SNI, whereas I believe it normally does with SChannel.
- causes
-
SERVER-36088 Replica set connection strings trigger access violation on 4.0 shell + Windows
- Closed
- depends on
-
CDRIVER-2658 Save minidump file if mongod crashes during test
- Closed
- is duplicated by
-
SERVER-36012 Crash in doServerHandshake
- Closed
-
SERVER-36088 Replica set connection strings trigger access violation on 4.0 shell + Windows
- Closed