1

I have my application(VC MFC) run with gflags with Pageheap enabled to track down the page heap corruption.

Now the application has crashed and it shows this error, I could not interpret these lines (other than having a feel of resource inavailablity)

Can anyone throw a light on what exactly is the reason that has caused the crash of the app?

(info: Application is a multithreaded one about 500 threads running,in a multi - processor machine)

kernel32!RaiseException+53 
msvcrt!_CxxThrowException+36 
mfc42u!AfxThrowResourceException+19 
mfc42u!AfxRegisterWndClass+ab 
mfc42u!CAsyncSocket::AttachHandle+5c 
mfc42u!CAsyncSocket::Socket+25 
mfc42u!CAsyncSocket::Create+14
sth
  • 222,467
  • 53
  • 283
  • 367
buddy
  • 805
  • 1
  • 15
  • 30

3 Answers3

6

This same problem has driven me nuts but finally i fixed it and it is working. This is bug with MFC socket library that when inside a thread [other than main application thread], If we try to do something like

CSocket socket;
socket.Create();

It will throws an unhandled exception. I found an article on it See What Microsoft says about this

that said something from Microsoft but that did not help me either. So here is a workaround i have found and i hope it can help some frustrated fellow like me.

Inside thread, do this

CSocket mySock;
SOCKET sockethandle = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
mySock.m_hSocket= sockethandle;

After that DO NOT call mySock.Create as it has been created already through assignment of socket handle. I am not sure if we can use mySock.Attach(sockethandle) as i did not try it yet.

After that you can call Connect etc directly.

When you are done using the socket, DO NOT call mySock.Close() - rather call closesocket(mySock.m_hSocket); And that will free the socket object. If Attach works in above case then i guess we need to do Detach here when to free the socket.

Good Luck

Nauman Khan
  • 61
  • 1
  • 2
  • If it wasn't for your post here I wouldn't have found my problem. I was trying to make an old MFC application work as a service and I couldn't figure out why I couldn't call Create() and Listen() within the service. I was on the wrong track and thought it was something to do with Network Access privileges, but in fact it had to do with this and the fact that CAsyncSocket needs a window. Attach() still doesn't work within the service, but at least now I know from where the problem is coming. I'll probably just write my own CSocket implementations using WinSock. Thanks a million! – jbx Dec 22 '12 at 11:46
0

I wonder if this is your actual heap corruption issue, or if your program has just hit a resource limitation as a consequence of running with Pageheap.

I can't remember the exact details, but Pageheap incurs extra memory overhead, so much so that you can run out of memory much sooner than you would without Pageheap enabled.

With 500 threads running, you have a 1MB stack for each, plus any memory they've allocated dynamically along the way.

CAsyncSocket::AttachHandle triggers AfxThrowResourceException if it can't create a window. It seems that your system is saturated due to Pageheap.

Do you have to have 500 threads running to reproduce the problem? Maybe if you could lower that count a little, there would be more resources available.

Kim Gräsman
  • 7,438
  • 1
  • 28
  • 41
  • Yea Page heap demands more memory, but what we wanted is the heap corruption injection point. if we make our appln run in this loaded condition, the application crashes. Here is another point of crash, many instances it has crashed in this particular location, provided we are running the application in a high end machine ( 8 core & 4 GB RAM) mfc42u!CFixedAlloc::Alloc+5c mfc42u!CString::AllocBuffer+25 mfc42u!CString::CString+3e WP_Communications_Server!CWPGenericService::AddToMessageLog+b9 Any clue? we are stuck in this problem for more than 2 weeks. – buddy Jul 20 '09 at 11:14
  • Do you need Full Pageheap, or could you try with Normal, per http://support.microsoft.com/kb/286470? Since your heap is corrupted, it could crash anywhere. You never answered my question -- is there a chance of reducing the amount of threads running to conserve resources during the test? Or does the behavior only rise when you have 500 threads running? – Kim Gräsman Jul 21 '09 at 07:10
0

I had the same problem, and after trying many things I've notice the following CAsyncSocket reference:

Create is not thread-safe. If you are calling it in a multi-threaded environment where it could be invoked simultaneously by different threads, be sure to protect each call with a mutex or other synchronization lock.

After adding a Mutex synchronization it no longer throws an exception.

Haim
  • 1