CDialog based app is crashing on exit at AFX_MODULE_STATE::~AFX_MODULE_STATE()

Hi,

I have a Cdialog based modal dialog application that is crashing on exit in release only. I do nothing with the dialog except open it and then close it by using the "x" of windows. it's an mfc project using dynamically linked dlls.

The app is a global object, and a modal dialog is created in its initInstance.

the app crashes at the line delete m_pDaoState;(in afxstate.cpp)

The value of the pointer is invalid.. Access violation.

AFX_MODULE_STATE::~AFX_MODULE_STATE()

#ifndef _AFX_NO_DAO_SUPPORT

delete m_pDaoState;

// clean up type lib cache map, if any

if (m_pTypeLibCacheMap != NULL)

delete m_pTypeLibCacheMap;

Nick.

The Value of the pointer is NULL...0x0000(something)

it looks like it was already deleted.

This seems to correspond to the global App object and I have no clue why this should happen. I don't see it crashing in debug, only release.

No, it isn't NULL; "delete(0)" is legal. What's the real value of the pointer What does "(something)" mean

Perhaps it is the variable itself that is null, not the value of the variable.

Sorry, I have no idea what that means. The pointer is either NULL or it isn't. The fact that a call to "delete(pointer)" causes an AV means that

1) the pointer is not NULL, but

2) it points to the wrong place

And, actually, he's lucky he got the AV; the pointer could have just as easily pointed to a valid address, and he'd end up with heap corruption that didn't show up until later.

He didn't say the pointer was NULL/zero; he said it was "NULL...0x0000(something)". Another "mystery" phrase: unless "(something)" is 4 more zeros, the pointer isn't NULL, so (like I said) somebody wrote a bogus value into it, and he needs to find out who and where. A data breakpoint is the easiest way to do that.

nick78 wrote:

I have a Cdialog based modal dialog application that is crashing on exit in release only. I do nothing with the dialog except open it and then close it by using the "x" of windows. it's an mfc project using dynamically linked dlls. The app is a global object, and a modal dialog is created in its initInstance.

Okay...so I assume this is the main dialog of the application. I am not sure what you mean with dynamically linked dlls though, do you load them at run-time Nonetheless, do a simple test: What happens if you don't load/link these dlls Start the application, show the dialog and click on the 'x'. What happens

nick78 wrote:

the app crashes at the line delete m_pDaoState;(in afxstate.cpp) The value of the pointer is invalid.. Access violation.

Well...this message is pretty clear...you are accessing invalid memory. If it crashes at the given line, the pointer cannot be 0 (as others have pointed out, if it would be 0 there would not be an issue). Whether the pointer gets deleted twice or points to invalid memory is of course hard to say right away.

Looking at your description, I somehow have the feeling that you e.g. write over the boundary of an array somewhere else and the array happens to be just before the pointer and thus the pointer address gets overwritten.

Do you have the callstack available

Sdi wrote:

Sorry, I have no idea what that means.

You could if you wanted to.

Sdi wrote:

The pointer is either NULL or it isn't.

I did not say the pointer.

Sdi wrote:

And, actually, he's lucky he got the AV; the pointer could have just as easily pointed to a valid address, and he'd end up with heap corruption that didn't show up until later.

If my theory is what is happening, and I am only guessing at a possible explanation, then the pointer does not exist.

The following causes an assertion using a debug build in VC 6. It should cause a problem of some kind regardless of build and version. In "delete ptd->m_p" the pointer does not exist, or at least should not exist and the behavior is definitely undefined.

Simple Samples wrote:

If my theory is what is happening, and I am only guessing at a possible explanation, then the pointer does not and cannot point to anything. The following causes an assertion using a debug build in VC 6. It should cause a problem of some kind regardless of build and version. In "delete ptd->m_p" the pointer does not exist, or at least should not exist and the behavior is definitely undefined. Code Block class TestDelete { public: TestDelete() : m_p(new int) {}; int *m_p; }; Code Block TestDelete *ptd; ptd = new TestDelete; delete ptd; delete ptd->m_p;

Andreas Masur wrote:

Which actually could only occur in this scenario if the the class 'AFX_MODULE_STATE' would already be deleted and thus the class members would be invalid. However, the crash occurs inside the destructor so this actually cannot be the issue here. If I convert this to your example...the code we are looking at right now is equivalent to: Code Block class TestDelete { public: TestDelete() : m_p(new int) {}; ~TestDelete() { delete m_p; }; int *m_p; }; Code Block TestDelete *ptd; ptd = new TestDelete; delete ptd; And this is perfectly valid...unless someone invalidates the address 'm_p' is pointing to...

There is another possibility that could occur. Using the TestDelete definition above with the destructor, the following would be a problem:

Please delete the line

m_pMainWnd = &dlg;

and try again

Hi

Thanks for all your eplies...

I basically start the app and then close it using "x"...nothing else.

The app crashes in release at the said place. No assertions or crashes in debug...

The pointer value is 0x00000(something - definitely NULL) , it's in the destructor of module st6ate as indicated...definitely looks like deletion of memory that's already gone...The exact text of the message is " Application Error - The instruction at 0x00c0e350 referenced memory at 0x6e657478. The memory could not be "read". Click Ok to terminate the program."

Thanks.