FIX: Assertion Failed, Line 475 of Sockcore.cpp

• The Microsoft Foundation Classes (MFC), included with:
  • Microsoft Visual C++ for Windows, 16-bit edition, version 1.52
  • Microsoft Visual C++, 32-bit Editions, versions 2.1, 2.2

SYMPTOMS

An MFC application that uses the socket classes and makes sequential calls to close and create sockets encounters an assertion failure:

In MFC 3.1 and 3.2, the assertion appears as:

Assertion Failed: <app name>: File sockcore.cpp, Line 475

Assertion Failed: <app name>: File sockcore.cpp, Line 456

CAUSE

MFC maintains a map of dead sockets. (A dead socket is a socket that was open but that has been closed.) The purpose of this map is described in further detail in the "More Information" section of this article.

If an application closes and opens sockets in the same thread without yielding to process messages, then it is possible that an attempt will be made to close a socket that has already been closed. MFC does not properly handle this because it can only have one entry in the map of dead sockets. The resulting assertion failure is checking whether there is already an entry in the map of dead sockets:

   ASSERT(CAsyncSocket::LookupHandle(hSocket, TRUE) == NULL);
   // The TRUE means it is looking for a dead socket handle,
   // thus the assertion failure occurs. 

RESOLUTION

There are four possible resolutions:

• The problem occurs only if you are closing and opening sockets sequentially without yielding to process messages. If you are doing this to send many small packets of data, there might be other approaches that would work better. See the "More Information" section of this article for further details.


-or-


• One pretty simple resolution is to suspend the closing of any sockets until all sockets have been opened. This prevents any new SOCKET from being opened (and subsequently closed) that happens to have the same SOCKET handle as a previously closed socket.


-or-


• You can write a routine to process all pending socket messages immediately after calling Close and before continuing with code execution. This could be done, for example, in the Close member function of your own CAsyncSocket-derived or CSocket-derived class:

  
     #include <afxpriv.h>
  
     void CMySocket::Close()
     {
       // For the socket about to be closed.
       SOCKET hDeadSocket = m_hSocket;
  
       CAsyncSocket::Close();
       // or for CSocket-derived class:
       // CSocket::Close();
  
       MSG msg;
       CSocket::ProcessAuxQueue();
       while(::PeekMessage(&msg,NULL,
               WM_SOCKET_NOTIFY,WM_SOCKET_DEAD,PM_REMOVE))
       {
         ::DispatchMessage(&msg);
         if( (msg.message==WM_SOCKET_DEAD) &&
             ((SOCKET)msg.wParam==hDeadSocket))
           break;
       }
     } 

  The virtual destructor should also be overridden to make sure the correct Close is called:

  
     CMySocket::~CMySocket()
     {
       if (m_hSocket != INVALID_SOCKET)
         Close();
     } 

  NOTE: This will cause CAsyncSocket-overriden and CSocket-overridden callbacks (for example, OnReceive, OnAccept) to be called for any currently open sockets that have notification messages pending in the queue.


-or-


• Restructure the code so that the Close/Open operations are not in a non- yielding sequence. This could be done by providing a message handler for a user-defined message and by performing a specific operation in that message handler. Rather than just proceeding with the thread of execution, a function call that Closes or Destroys a CAsyncSocket/CSocket object should be followed by a PostMessage with the user-defined message. This way all other messages (including the WM_SOCKET_DEAD message) will be processed before the subsequent socket operations are performed.

STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. This problem was corrected in the version of MFC that ships with Microsoft Visual C++, 32-bit Edition, version 4.0.

MORE INFORMATION

Sending Small Packets of Data

Using One Persistent Connection

Using DATAGRAM Sockets

The WM_SOCKET_DEAD Mechanism

1. The SOCKET handle is removed from the map of attached sockets.



2. The SOCKET handle is placed in the map of dead sockets.



3. The WM_SOCKET_DEAD message is posted to the application's message queue with a wParam indicating the closed SOCKET handle.

1. The message routing mechanism for MFC's hidden socket notification window ignores all messages for a SOCKET handle while the SOCKET handle is in the map of dead sockets.



2. The SOCKET handle is not removed from the map of dead sockets until the WM_SOCKET_DEAD message is received.

Additional query words: 2.52 2.10 2.20 3.10 3.20 4.00 CSocket CAsyncSocket

Keywords : kbMFC kbVC kbWinsock
Version : 1.52 | 2.10 2.20
Platform : NT WINDOWS
Issue type :