Access violation only in release build with debug info

[AlexO]

s_k wrote: __REBARBANDINFO rb; __rb.cbSize=sizeof(REBARBANDINFO); __// THIS IS PROBLEM FUNCTION __RCtrl.GetBandInfo(0,&rb); try _REBARBANDINFO rb; ::ZeroMemory(&rb, sizeof(REBARBANDINFO)); __rb.cbSize=sizeof(REBARBANDINFO);

[s_k]

IT WORKS!! I thank you so much! Anyway, if you answered me this question, I would be even more happy: How is it possible that neither in debug version nor in release version without debug info no access violation appeared? Maybe I would understand difference between debug and clean release version, but what the heck is difference between, we can say, two DEBUG versions? Thank you again, AlexO, I really appreciate your help!

[Neville Franks]

A few things I'd try: 1) Always test functions succeed. In particular CreateEx(), Create() etc. 2) In CMainFrame::ChangeDlgBar() add: ASSERT_VALID( this ); ASSERT( ::IsWindow( m_hWnd ); ASSERT( ::IsWindow( m_wndDoubleDiscBar.m_hWnd ) ); __CReBarCtrl& RCtrl = m_wndDoubleDiscBar.GetReBarCtrl(); ASSERT_VALID( &RCtrl ); ASSERT( ::IsWindow( RCtrl.m_hWnd ); Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com

[s_k]

Thanks Neville! Fortunately, AlexO has already found the cause of the problem - I have to call ::ZeroMemory to zero REBARBANDINFO structure. Never thought this may be reason for CWnd::FromHandlePermanent() to return NULL...

[Neville Franks]

Yes I saw Alex's post just after I sent mine. Initialization issues like this can be hard to track down and the outcome can vary depend on what crap happens to be being set. Bottom line is your back in business. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com

[Anthony_Yio]

In debug mode build, the linker assigns bogus size storage for each block. When you accidentally forgotten to delete or deinitialize some component. The extra size storage in each other block can still cater as it had not touched the actual content. But once the linker had swicthed to release mode. All the storage blocks were optimise to it supposing size. When you have crossing action in your code, straight up a access violation will pop up. I read this in one of codeproject article. Can't remember the title already but hope this helps.

[AlexO]

It is very common error in debug vs. release. The problem is debug memory allocation it usually initializes memory to 0 or 0xcdcdcdcd. Release memory is not initialized so values are random. Example: DWORD dwSize; //not that is not initialized SomeFunction(&dwSize);//note dwSize is in/out parameter the example above might work in debug but will blow up in release.

[s_k]

I don't understand. dwSize is just local variable. Its address (as passed to SomeFunction()) will be always valid, won't be? Of course SomeFunction() mustn't do something like this: TCHAR* s = new TCHAR[dwSize]; because dwSize was not initialized, but the code you posted itself is valid as long as I don't know SomeFunction() code...

[AlexO]

no, I did not mean address. Imagine that inside that function you have soemthing like int SomeFunction(DWORD* dwSize, char* actualBuffer) { if(*dwSize > 0) { char* pCopy = new char[*dwSize]; ::memcpy(pCopy, actualBuffer, *dwSize);//this is where error will manifest itself if you forgot to initialize dwSize, in release dwSize could be anything, in debug it would probably be zero so we never come here ... } ... } P.S. Real scenario is usually more complex but idea is the same

[s_k]

Yes, I understand now, that's what I thought could really cause problems...