Bug fixes

Bug in the 6.5.5 changes for the read timeout connection filter

The recent changes to 6.5.5 so that JetByteTools::Socket::CReadTimeoutStreamSocketConnectionFilter holds a socket reference when the timer is set causes problems when the socket is shutdown. The filter doesn’t see the shutdown and fails to cancel the timer which means that a reference is held on the socket until the timeout expires. This delays socket closure and causes your timeout handling code to be run on a socket which has been cleanly shut down.

The advantage of having lots of clients and clients with lots of clients

Our Secretive Online Game Company client uses The Server Framework for their custom application server for the games industry. They have thousands of users who run their server on a very diverse set of hardware. This is great for us as it really helps to shake down The Server Framework. There’s nothing like running your multi-threaded code on lots of different hardware to help find all of the hidden race conditions and whatever.

Bug in CStringConverter::WtoA().

There’s a bug in CStringConverter::WtoA() when the default system code page is set to a multi-byte code page. The result is that the call will fail with an exception stating that “The data area passed to a system call is too small”. This was due to some naive code page handling (or lack of handling) in the code that determined the required buffer size. This bug will be fixed in release 6.

Bug fix for 6.3.x CServiceManager.cpp

There’s a stupidly obvious, should have been caught at numerous points during pre-release testing, bug in CServiceManager.cpp. The code below that starts at line 158: case RunActionRunAsService : { if (!StartServices()) { const DWORD lastError = ::GetLastError(); const _tstring message = messageHeader + _T("Failed to start service.\n\n ") + GetLastErrorMessage(lastError); MessageBox(message); result = 2; } } default : throw CException(_T("CServiceInstanceManager::Run()"), _T("Unexpected run action:") + ToString(runAction)); } Should actually look like this, note the inclusion of the missing break; and the exception source correction:

Potential to deadlock in OpenSSL, SChannel and SSPI Negotiate connectors

I’ve been improving my pre-release testing system and now run a lock inversion detector as part of my build machine’s build and test cycle for the socket server examples. This lock inversion detector can detect the potential to deadlock without the code ever needing to actually deadlock, so it’s a pretty powerful tool. It has detected a lock inversion in the async connectors used by the OpenSSL, SChannel and SSPI Negotiate libraries.

Bug in OpenSSL stream socket filter which causes memory leaks

There’s a bug in the OpenSSL stream socket filter which results in I/O buffers being leaked on both inbound and outbound data flow. This causes the memory used by the client or server to grow throughout the life of the process. The bug has been present since release 6.2 when the structure of the filtering code was redesigned. Note that due to the fact that the filtering code was all redone at that time I expect that the same bug is likely to be present in the SChannel, SSPI and compression filters.