Debug Assertion in Release wrong version of MFC Shared DLL
-
HI, I have code that works fine in debug but I have already learned my lesson that it does mean It will work in Release Anyway I got an assertion in wincore.cpp line 656 for having a window handle = NULL After the message box came up pointing me to the location in wincore.cpp where the problem was I tried to attach the VS debugger with my solution. Wasn't much help as the call stack was all windows code One thing I did notice that was odd the DLL was MFC140d.DLL isn't that the debug version of MFC I checked my property pages for release and I had /MD not /MDd shouldn't I have MFC140.DLL ??
-
HI, I have code that works fine in debug but I have already learned my lesson that it does mean It will work in Release Anyway I got an assertion in wincore.cpp line 656 for having a window handle = NULL After the message box came up pointing me to the location in wincore.cpp where the problem was I tried to attach the VS debugger with my solution. Wasn't much help as the call stack was all windows code One thing I did notice that was odd the DLL was MFC140d.DLL isn't that the debug version of MFC I checked my property pages for release and I had /MD not /MDd shouldn't I have MFC140.DLL ??
Turn your warning level up .. it will give you uninitialized use warnings. The default is W3 go to W4 or WALL you might get a lot of warnings but saves you headaches :-) I usually start out W3 when it's getting close to release I crank the setting up and walk thru each warning. What you are really saying is you have a bad habit of either using uninitialized variables or forgetting to initialize them which will be what your current problem is about. You need to work on getting rid of what is obviously a bad coding habbit. /MD is the correct selection for the VC runtime library release but usually I go for /MT in release the exe gets bigger but no VC runtime install required on the target machine. Now I assume it follows thru to MFC I write so little on the MFC framework I can't say definitively. But yes usually in release /MD or /MT is the setting you would use the difference as stated, and if the blowup in size is worth not having to distribute the run-time library at all. Now when VS debugs in release mode it's a quirky thing, as you stated you wanted no debug compilation but the VS IDE still tries to give you debug info. It seems to sort of guess at the line sometimes you will find it out by a line or 2 especially if it has optimized some of the code away. When running outside the IDE I know it only uses the correct DLL because the times I have used DLL distribution I only copy the one DLL for install.
In vino veritas
-
Turn your warning level up .. it will give you uninitialized use warnings. The default is W3 go to W4 or WALL you might get a lot of warnings but saves you headaches :-) I usually start out W3 when it's getting close to release I crank the setting up and walk thru each warning. What you are really saying is you have a bad habit of either using uninitialized variables or forgetting to initialize them which will be what your current problem is about. You need to work on getting rid of what is obviously a bad coding habbit. /MD is the correct selection for the VC runtime library release but usually I go for /MT in release the exe gets bigger but no VC runtime install required on the target machine. Now I assume it follows thru to MFC I write so little on the MFC framework I can't say definitively. But yes usually in release /MD or /MT is the setting you would use the difference as stated, and if the blowup in size is worth not having to distribute the run-time library at all. Now when VS debugs in release mode it's a quirky thing, as you stated you wanted no debug compilation but the VS IDE still tries to give you debug info. It seems to sort of guess at the line sometimes you will find it out by a line or 2 especially if it has optimized some of the code away. When running outside the IDE I know it only uses the correct DLL because the times I have used DLL distribution I only copy the one DLL for install.
In vino veritas
Thanks I just realized I did a number of SetDlgItemText for labels in my Dialog but I never Created a window Maybe I'll just have the appropriate CStatic's and use DDX_Control to initialize the windows handle or better yet just use DDX_Text and put the data in a CString Thanks
-
HI, I have code that works fine in debug but I have already learned my lesson that it does mean It will work in Release Anyway I got an assertion in wincore.cpp line 656 for having a window handle = NULL After the message box came up pointing me to the location in wincore.cpp where the problem was I tried to attach the VS debugger with my solution. Wasn't much help as the call stack was all windows code One thing I did notice that was odd the DLL was MFC140d.DLL isn't that the debug version of MFC I checked my property pages for release and I had /MD not /MDd shouldn't I have MFC140.DLL ??
For some reason your release build is linked with the debug version of the MFC. You should find out why and fix that. A possible reason is linking with another DLL that depends on the MFC DLL and is a debug version itself. With proper code, a debug build should also assert at that point (window handle NULL). However, it would not assert if the handle is not NULL but invalid (uninitialised variable). But then you usually get other runtime errors.
-
For some reason your release build is linked with the debug version of the MFC. You should find out why and fix that. A possible reason is linking with another DLL that depends on the MFC DLL and is a debug version itself. With proper code, a debug build should also assert at that point (window handle NULL). However, it would not assert if the handle is not NULL but invalid (uninitialised variable). But then you usually get other runtime errors.
-
My only guess at this point that after doing various "new" to allocate heap storage to format labels for the dialog I do AfxCheckMemory rather then assert to see if I some how over stepped my storage allocation Thanks
This function works only in the Debug version of MFC.
Therefore, it is common to call that within an
ASSERT(). Note also that you should check if the affected handle is on the heap. It does not help when it is on the stack. -
This function works only in the Debug version of MFC.
Therefore, it is common to call that within an
ASSERT(). Note also that you should check if the affected handle is on the heap. It does not help when it is on the stack.I am quite sure the reason I got an assertion was because I did a SetDlgItemText without some how creating a m_hWnd Just surprising that it worked at all under debug but then again I am beginning to understand the "debug" version covers up for a lot of mistakes On more thing should assert only be used in "debug" Thanks
-
I am quite sure the reason I got an assertion was because I did a SetDlgItemText without some how creating a m_hWnd Just surprising that it worked at all under debug but then again I am beginning to understand the "debug" version covers up for a lot of mistakes On more thing should assert only be used in "debug" Thanks
Quote:
I am quite sure the reason I got an assertion was because I did a SetDlgItemText without some how creating a m_hWnd
That is very likely.
ForNow wrote:
On more thing should assert only be used in "debug"
Just read the documentation:
assert Macro, _assert, _wassert[^]
The assert macro is enabled in both the release and debug versions of the C run-time libraries when NDEBUG is not defined. When NDEBUG is defined, the macro is available but does not evaluate its argument and has no effect. When it is enabled, the assert macro calls _wassert for its implementation. Other assertion macros, _ASSERT, _ASSERTE and _ASSERT_EXPR, are also available, but they only evaluate the expressions passed to them when the _DEBUG macro has been defined and when they are in code linked with the debug version of the C run-time libraries.
My tip: Use them often (e.g. on top of functions for parameter checking and with function return values when there is no error handling). They are simply ignored in release builds but can save you a lot of debugging time.