DEBUG vs. RELEASE
-
Does anybody know if there is a common or wellknown behaviour why an MFC-Application works flawlessly in DEBUG-Mode and suddenly when compiled in RELEASE-Mode throws the unhandled exception 0x00000005:Access violation??? Manfred --- Programming is knowing...
-
Does anybody know if there is a common or wellknown behaviour why an MFC-Application works flawlessly in DEBUG-Mode and suddenly when compiled in RELEASE-Mode throws the unhandled exception 0x00000005:Access violation??? Manfred --- Programming is knowing...
We're working through a couple of similar bugs here right now, and this URL http://codeguru.earthweb.com/debug/ReleaseMode.shtml is full of good advice. One other thing you can do is change TRACE to OutputDebugString, and you'll get tracing in release mode. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
-
We're working through a couple of similar bugs here right now, and this URL http://codeguru.earthweb.com/debug/ReleaseMode.shtml is full of good advice. One other thing you can do is change TRACE to OutputDebugString, and you'll get tracing in release mode. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
Thanks Chris - it's once again YOU to help me (try to) out of a problem. OnPaint() is working now as it is supposed to... Also thanks to all the other Gurus: 'Funky' Erik (Funkenbusch) and Lauren (I like the colours of your homepage)... The unhandled exception 0x00000005:Access Violation occurs in a WIN callback-function. When I open some MIDI-Input with
midiInOpen(&hMidiIn, CurInDevice, (DWORD)MyCallback, NULL, CALLBACK_FUNCTION);
The 3rd parameter is the address of a callback-function which is called by the Midi-Device-Driver everytime a MIDI-Event has arrived its input. The callback works as follows:
void CALLBACK MyCallback(HMIDIIN hMidiIn, UINT wMsg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2)
{int iResult;
switch(wMsg)
{case MIM_DATA:
{
iResult = Zones->PostMessage(WM_MIDIEVENT); //Zones is the Main-Window of my Dialog-based App
ASSERT(iResult);
break;
}case MIM_MOREDATA: break;
case MIM_OPEN: break;
case MIM_CLOSE: break;default:
ASSERT(0);}
So the callback only posts a userdefined message
#define WM_MIDIEVENT WM_USER+100
to my Dialog. The MessageMapEntry
ON_MESSAGE(WM_MIDIEVENT, OnMidiEvent)
is for now just a stub - doing nothing...
void CZones::OnMidiEvent()
{
}When the first MIDI-Event arrives everything works fine, but as soon as the second event drops in I may not move the mouse over the System-Menu or click the Dialog or move over a checkbox in the dialog. As long as I don't move the mouse I can play as many notes as I want... BTW: When the Dialog is minimized everything works flawlessly too. But I only have to right-click into the task-bar.....EHHHHHH No context-menu for maximizing or closing - just my unhandled exception 0x00000005:ACCESS-VIOLATION Any Ideas on that ? The exception appears on two machines exactly at the same address. In DEBUG-MODE everything works brilliant, no latency (MIDI-delays) no MIDI-drones (sounding till you shut down your system) - no really professional... Manfred --- Programming is knowing...
-
We're working through a couple of similar bugs here right now, and this URL http://codeguru.earthweb.com/debug/ReleaseMode.shtml is full of good advice. One other thing you can do is change TRACE to OutputDebugString, and you'll get tracing in release mode. Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
I followed your advice, Chris - and went to your CodeGuru link. http://codeguru.earthweb.com/debug/ReleaseMode.shtml There was one comment by Kelly Beyer: 'Incorrect Message Map Function Signatures' which referred to a MSDN-KnowledgeBase article. http://support.microsoft.com/support/kb/articles/Q195/0/32.ASP So I changed the handler macro of my User-defined message from
afx_msg void OnMyMessage(void);
to
afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);
And my handler-function from
void MyDialog::OnMyMessage(void);
to
LRESULT MyDialog::OnMyMessage(WPARAM, LPARAM);
And now it works. In all my books showing how to write User-defined messages it is done the wrong way. No explanation that the signatures have to be exactly like the ones above. They all used 'void' instead - and as, when being a beginner, you seldomly switch to release-mode you never realize that there is a little bug in your application. And when you do it once than you'll never find out when this bug silently came into your app. Though it's hard to put the blame on a User-defined message that worked for months in DEBUG-MODE. Believe me: You would take everything else under consideration before this... But at least I think it is a very bad behaviour that the compilor doesn't give you at least a warning when working in DEBUG-MODE (I'm only working in 'Warning-Level 4'). I would never have found the bug in my app without that articles on the net. There is one little question still bugging me as I got a little paranoid now. Do you think that this is the real solution to my problem or is it just a temporary workaround that is hiding another surprise for me now for the future??? Does it sound like 'there must be something else' to you ??? Thanks again for your help - this time a hit, not only a try... Manfred --- Programming is knowing...(and having better friends than the MicroSofties)
-
I followed your advice, Chris - and went to your CodeGuru link. http://codeguru.earthweb.com/debug/ReleaseMode.shtml There was one comment by Kelly Beyer: 'Incorrect Message Map Function Signatures' which referred to a MSDN-KnowledgeBase article. http://support.microsoft.com/support/kb/articles/Q195/0/32.ASP So I changed the handler macro of my User-defined message from
afx_msg void OnMyMessage(void);
to
afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);
And my handler-function from
void MyDialog::OnMyMessage(void);
to
LRESULT MyDialog::OnMyMessage(WPARAM, LPARAM);
And now it works. In all my books showing how to write User-defined messages it is done the wrong way. No explanation that the signatures have to be exactly like the ones above. They all used 'void' instead - and as, when being a beginner, you seldomly switch to release-mode you never realize that there is a little bug in your application. And when you do it once than you'll never find out when this bug silently came into your app. Though it's hard to put the blame on a User-defined message that worked for months in DEBUG-MODE. Believe me: You would take everything else under consideration before this... But at least I think it is a very bad behaviour that the compilor doesn't give you at least a warning when working in DEBUG-MODE (I'm only working in 'Warning-Level 4'). I would never have found the bug in my app without that articles on the net. There is one little question still bugging me as I got a little paranoid now. Do you think that this is the real solution to my problem or is it just a temporary workaround that is hiding another surprise for me now for the future??? Does it sound like 'there must be something else' to you ??? Thanks again for your help - this time a hit, not only a try... Manfred --- Programming is knowing...(and having better friends than the MicroSofties)
Yes, i believe it. This bug used to catch me all the time. Now i've learned to always do ON_MESSAGE handlers the LRESULT way. there is a "ON_MESSAGE_VOID" message handler, but i've never used it and i don't know if it will help. (from Afxpriv.h)
// like ON_MESSAGE but no return value
#define ON_MESSAGE_VOID(message, memberFxn) \
{ message, 0, 0, 0, AfxSig_vv, \
(AFX_PMSG)(AFX_PMSGW)(void (AFX_MSG_CALL CWnd::*)(void))&memberFxn },-c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com