Exception Handling MFC detail information

Lost User

Hey, If you spend a few minutes to setup GFlags... you should quickly find the source of the heap corruption. Where to get GFlags[^] This is a very powerful tool... and you will become a much better engineer if you learn how to use the Windows debugging tools. Note that GFlags is not just for kernelmode... you can enable per-process heap monitoring in usermode processes: Detecting Heap Corruption Using GFlags and Dumps[^] Best Wishes, -David Delaune

ForNow

I tried it the Dialog Version of flags and this this time there was not a exception break however I knew there is a problem because my stream in code didn't work meaning it didn't show the text , typically when that happens there are some very subtle storage overlays or memory exceptions as you mentioned when running in debug mode they sometimes show and sometimes don't So I just started taking my code apart removing all the control just having the rich edit and the text was displayed I'll put the code for the control back one at a time until I find the exception thanks

Victor Nijegorodov

ForNow wrote:

BTW wparam is a pointer from tcp/ip message/buffer and lparam is the length

Is this message sent or posted?

ForNow

this is the code that is causing the exception

LRESULT CprogDebug::GET_ZOS_STORAGE(WPARAM mywparam, LPARAM mylparam)
{

mystorage\[I\]->len = mywparam;
mystorage\[I\]->buffers = new char\[mystorage\[I\]->len\];
memcpy((void \*)mystorage\[I\]->buffers, (void \*)mylparam, mystorage\[I\]->len);
mystorage\[I\]->casid = as\_id;
    mystorage\[I\]->Create(IDD\_DIALOG6, NULL);

return TRUE;

}

The code is invoked from a postmessage I.E

::PostMessage(thisocket->callwnd,thisocket->msg,(WPARAM) nRead,(LPARAM)sockbuffer.GetBuffer(0));

Victor Nijegorodov

ForNow wrote:

The code is invoked from a postmessage I.E

::PostMessage(thisocket->callwnd,thisocket->msg,(WPARAM) nRead,(LPARAM)sockbuffer.GetBuffer(0));

I guess that in a time the message is handled in your main thread the variable sockbuffer might go out of scope. The result - the memory exception. Is this message is posted from the other (socket) thread? Anyway, check out this great J.Newcomer essay: [WorkerThreads](http://flounder.com/workerthreads.htm)

ForNow

yes it is thanks

Lost User

ForNow wrote:

::PostMessage(thisocket->callwnd,thisocket->msg,(WPARAM) nRead,(LPARAM)sockbuffer.GetBuffer(0));

As Victor is implying... change this to use SendMessage [^] and see if your problem goes away. Best Wishes, -David Delaune

ForNow

That wasn't it I think its something with the storage allocation .. the new

David Crow

What is the value of mystorage[I]->len? Is mystorage[I]->buffers non-null before calling memcpy()?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

ForNow

mystorage[I}->len has the right value, I didn't check mystorage[I]->buffers for non NULL but it has an address and the right data after the memcpy However as Victor pointed out sockbuffer is from a different thread I knew something was wrong when my rich edit didn't get populated running under the debugger subtle storage overlays don't cause exceptions I have a question if invoke exception handlers ( and I have to read up on it) will it catch the exceptions that the VS debugger bypasses Thanks thanks

Bram van Kampen

Well, You have another post about the failures of optimizers. Do those threads relate to the same problem? (or even the same problem?) I understand that you are in a state of desperation. Believe me, I've been there myself, many times and more. When all other options fail, you are left with nothing else left to blame, but the compiler. I must say, I use a Windows NT version of the Development Environment hailing back to 1998, and, that has indeed a few issues, which I have now documented and hence avoid. For Instance, Standard Code like:

for(int i=0;i
worked in Debug, but caused an exception in Retail.
The Work around was simple:

int i; for(i=0;i

Be Realistic, anything drastically wrong with the MFC Compiler or MFC Libraries, would very soon have thrown up issues world wide.

I understand that your code runs flawless in the Debug version, but bails out in the retail version. The difference between the two builds are far bigger than the application of an optimisation process. For starters they link into different MFC Libraries.

Have you tried: [Why Program works in debug but not release mode](https://social.msdn.microsoft.com/Forums/vstudio/en-us/1ce70392-5e84-4fcb-925d-f8acb47a030d/why-program-works-in-debug-but-not-release-mode?forum=vclanguage) By Microsoft, or, [Surviving the Release Version](https://www.codeproject.com/Articles/548/Surviving-the-Release-Version) in our own Code Project Site.

There is something trivial wrong with your code, that your compiler can read and interpret without generating a syntax error, but which also does something quite different than what you intended it to do, and causes an exception to be thrown in release mode. The Debug mode tends to be more tolerant of (wittingly or unwittingly) doing 'Smart' things.

In order to allow us to help you, show us some (or Much) of the offending Code by attachment.
Regards, :)

Bram van Kampen

Bram van Kampen

Ah We are getting Somewhere! At least some code. On the Off Chance of asking a stupid question, I do not see any declarations for the Index 'I', nor for the class 'mystorage', nor for the object 'as_id'. Are you working on a PC or an IBM Main Frame, with z/OS Operating System. I am getting Confused! :)

Bram van Kampen