omit frame pointers and deallocate

[rskalgutkar]

I had been allocating and deallocating arrays within a dll with CVF as the compiler with no problems. I recently installed IVF 9.0 and converted my CVF project to IVF 9.0. Then I found that my dll crashes when I try deallocating the arrays in the Release configuration (worked with CVF). I got a Message Box about the deallocate call getting a pointer to a non-existent array or something like that just before the crash with a whole lot of other information. When I used the "allocated" function on the array, the result was "false", which is odd. The program is happy if I omit the deallocate function altogether and let the system handle(?) the deallocation. Later, I discovered that in Debug mode that the deallocate call works just fine and the "allocated" function returns true for the array!

Looking at the Project settings, I changed the "Omit Frame Pointers" option to "No" (/Oy-) in the Release configuration. This is the default setting in the Debug configuration. Now everything works just fine and a call to deallocate does not cause the dll to crash. The "allocated" function returns true for the array.

I briefly searched Intel's help for deallocation and did not find anything about the /Oy- option.

My question: why is it necessary to set /Oy- to allow deallocate to work properly or am I doing something wrong here?

[Steven_L_Intel1]

I can't think of why that would matter, unless your code was stepping on memory it shouldn't and changing the stack layout caused the error to become visible.

I'd like to see a test case - please submit it to Intel Premier Support.

Just checking first - you do know about the different default calling conventions in IVF? If you call your DLL from, say, VB and you didn't use the project conversion wizard (which sets the conventions to match CVF), you could corrupt the stack.

[rskalgutkar]

I will submit the code to Intel Premier Support. I am aware of the calling convention setting. I used the project conversion wizard which sets the calling convention to "CVF". I usually change it back to "Default" and instead use:

!dec$attributes stdcall, reference, dllexport, alias:'myDLL'::myDLL

which seems to work fine in all cases (until now?). I did get an error message from my VBA code saying that I have a bad dll calling convention but I guess I thought the culprit is in the Project settings after I realized that my code worked well in the Debug configuration. No error messages or crashes.