Description
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.
Attachments
Issue Links
- 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
-