Unhandled Exception Using MFC Sockets in Visual C++ 6.0

Will Beattie

I am running VC++ Vn 6.0 SP5 and am writing a program using multiple threads with CSockets. I am having problems i.e. Popup Dialog with: Microsoft Visual C++ Debug Library Debug Assertion Failed! File: sockcore.cpp Line: 567 This type of problem is documented on MSDN in an article "Q193101" acknowledging a bug in the static library. MSDN SP5 has a fix(?) for this and suggests adding "AfxSockInit()" to each each thread that uses sockets. I have done this and I am not getting assertions in the Release exe but I am still getting them in the debug version. Do I need new debug libraries, or should I just ignore the assertions - this is a "pita". suggestions welcome whybotha69@hotmail.com // the last C bug if (missilesDetected()); LaunchCounterAttack();

Ryan Binns

Debug assertions are used in the MFC library to indicate when the programmer has used the library in the wrong way, ie. you are doing something wrong. Run your app in debug mode and when the assertion comes up, hit debug, and try to trace what is actually causing the error. 99.9% of the time it's because you have made a mistake in your program and are using the library the wrong way. Ryan Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"

Will Beattie

Thanks for the comment, but I did all that and found the (mentioned) MSDN article. It was after exhausting all these avenues that I turned here !!

Ryan Binns

No problem, just checking the obvious first. At least somebody does the right thing ;) What line was the error on? I've never used the MFC socket classes - I prefer to use the Winsock APIs directly (I've done most of my sockets programming under Unix/Linux :)). I might be able to pick out some problems if you can tell me the file/line number though. Ryan Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"

Will Beattie

Thanks Ryans, File: sockcore.cpp Line: 567 It was in the original post (I stepped through the code) and the problem appears to be in ...\SOCKCORE.CPP starting at line 563 (the Line: 567 CAsyncSocket::FromHandle(...) part). #ifdef _DEBUG void CAsyncSocket::AssertValid() const { CObject::AssertValid(); ASSERT(m_hSocket == INVALID_SOCKET || CAsyncSocket::FromHandle(m_hSocket) != NULL); } Any news may be good news !! I am happy to send the Client and the server projects to anyone who may be able to assist!! cheers Will Beattie

Ryan Binns

It certainly looks like an internal library error. MFC maintains a map of socket handles to CAsyncSocket/CSocket objects. What this error is saying is that your socket handle is not mapped to a socket CAsyncSocket or CSocket object. If you're only using MFC socket classes, then it must be, and it's not being placed into the map properly. You might like to trace through from when you create (or accept, if it's an accepted socket) the socket, and see if it's being placed into the socket map. Other than this, I can't help any more. Ryan Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"

Baris Kurtlutepe

If this assertion fires randomly, i.e. it fires sometimes and especially when the connection is being or is closed, then please read further. Otherwise just ignore me. :) Actually this is an internal error and I don't think you're doing anything wrong at all. If it works fine in the release build, than that's it. I believe this is caused by the bad habit of abortive closing of the socket. The CAsyncSocket is a cumbersome implementation of winsock (and CSocket is much much worse) in which it uses hidden windows to receive asynchronous notifications and sometimes fails badly to handle the case, especially in abortive closures as I've mentioned. My assumption is that some window message(s) will get received after the socket has been closed and this assertion fires. Eventually it's not only that assertion on Line 567, there are many more you could face. Networking is chaotic due to the nature of connectivity and it's almost impossible to reproduce the problem, so that's why this assertion sometimes fires and sometimes does not and that's why I never succeeded in finding out the reason of the CAsyncSocket asserts. Though I'm not getting them that frequently (by the time of writing this I've noticed, I haven't got one since a month! :omg: I must have done something..) I've given up. Just blame it on Microsoft and everything's fine again. ;) Btw. CSocket and CAsyncSocket should really really be derived from CWnd. So, bad design + verygoodgodlikewhatever programming -> bad implementation.