invalid memory allocation not throwing exception but opening Windows message box?
-
I do have a wicked anomaly regarding an "out of memory" situation which behaves differently in two of my applications. Application 1, let it be called "tool", is an inhouse tool, MFC based with full MFC GUI and stuff. Application 2, let it be called "client", is a multiplayer game client, using MFC but only for the network socket, the whole GUI being custom on top of OpenGL/DirectX. Both applications are made with Visual C++ 2003.NET / v7.1.6030 unter WindowsXP. Only the "Release" mode is currently used. For exception handling of win32 exceptions both have the following project properties set...
Project Properties -> C/C++ -> Code Generation -> Enable C++ Exceptions = No
Project Properties -> C/C++ -> Command Line = /EHa...plus...
_set_se_translator(myfunction)
...is used (based on the information I found here[^]). But the wicked thing comes with memory allocation and the throwing vs. not-throwing of a std::bad_alloc exception. If I put the following code into both applications...
Byte* pData = NULL;
try {
int Amount = 0;
--Amount;
pData = new Byte[Amount];
}
catch (std::bad_alloc& E) {
// my own error handling
}...they behave differently: The "tool" behaves as I would expect and a std::bad_alloc exception is thrown, catched and my own error handling does the rest. But in the "client" a Windows message box comes up, simply telling me "Out of memory." with a black exclamation mark in a yellow triangle plus an OK button and if I press the OK button the application continues to run - which actually gives me a big "WTF?" moment. One way or the other that behaviour is neither intended nor appreciated. My best guess is that it depends on the compiler settings but I wasn't able yet to find any meaningful differences. I already experimented with optimization levels but couldn't change the application's behaviour doing so. Could anybody give me a hint on what the problem might be? Thanks, T.T.H.
-
I do have a wicked anomaly regarding an "out of memory" situation which behaves differently in two of my applications. Application 1, let it be called "tool", is an inhouse tool, MFC based with full MFC GUI and stuff. Application 2, let it be called "client", is a multiplayer game client, using MFC but only for the network socket, the whole GUI being custom on top of OpenGL/DirectX. Both applications are made with Visual C++ 2003.NET / v7.1.6030 unter WindowsXP. Only the "Release" mode is currently used. For exception handling of win32 exceptions both have the following project properties set...
Project Properties -> C/C++ -> Code Generation -> Enable C++ Exceptions = No
Project Properties -> C/C++ -> Command Line = /EHa...plus...
_set_se_translator(myfunction)
...is used (based on the information I found here[^]). But the wicked thing comes with memory allocation and the throwing vs. not-throwing of a std::bad_alloc exception. If I put the following code into both applications...
Byte* pData = NULL;
try {
int Amount = 0;
--Amount;
pData = new Byte[Amount];
}
catch (std::bad_alloc& E) {
// my own error handling
}...they behave differently: The "tool" behaves as I would expect and a std::bad_alloc exception is thrown, catched and my own error handling does the rest. But in the "client" a Windows message box comes up, simply telling me "Out of memory." with a black exclamation mark in a yellow triangle plus an OK button and if I press the OK button the application continues to run - which actually gives me a big "WTF?" moment. One way or the other that behaviour is neither intended nor appreciated. My best guess is that it depends on the compiler settings but I wasn't able yet to find any meaningful differences. I already experimented with optimization levels but couldn't change the application's behaviour doing so. Could anybody give me a hint on what the problem might be? Thanks, T.T.H.
Answering myself: Both applications seem to use different implementations of the new operator - despite both using the MFC: Application 1 uses the one from the CRT and throws a std::bad_alloc exception. Application 2 uses the one from the MFC and throws a CMemoryException*. According to "Binglong's Blog" (link see below) the actual choice which new operator will be used depends on (quote) "the operator new comes from the library the linker sees first". Ugh. What a mess. Unfortunately I was not able to define myself what "the linker sees first". If somebody has a handy hint, go ahead, will be very apprectiated! In addition to that there seems to appear some "Microsoftic Magical Trick": in case a CException is thrown ""somebody"" checks whether it will be catched - if yes, it the exception will be thrown, if not, the application will not simply crash but a message box will be displayed and the application can run on. Please note that this is an assumption based on my observation and to be honest I don't consider it helpful to wastespend more time on examining that behaviour further. Helpful links: Binglong's space: Operator new, STL memory allocator, and MSVC[^] Visual C++ 6.0: Don't Let Memory Allocation Failures Crash Your Legacy STL Application[^] Visual C++ exception handling[^]