Using Parallel Studio XE Pro V16.0 update 1 on Windows 7 Pro x64. Visual Studio 2013 (v120)
I have a test program written in C++, and compiled with Intel C++. This program allocates some arrays, initializes them, then calls a DLL written in Fortran. The Fortran DLL also performs additional allocations/deallocations. I am experiencing an issue where I observe intermittently some memory corruption (usually at the beginning of an array).
The error is observed in the Release build, but not in the Debug build. In an attempt to trace this down, I populated the code in the DLL with asserts. But left the original test program assert in place. Then re-ran the Debug build to confirm no new assert conditions.
I then went through the Fortran source file within the DLL changing the compiler options for optimization to maximum speed, and removed all runtime checks. I did this file-by-file for all the source files that did not contain the asserts. No assert triggered.
I then changed the optimization of the code containing the asserts to maximum speed and removed the runtime checks. Again, no assert triggered.
Next, I commented out the assert tests from deepest call stack upwards. Again no assert triggered.
I removed the final assert test, and have all but the DLL entry point compiled with optimization to maximum speed, and removed all runtime checks. Again no assert triggered (though this would have been triggered in the C++ test program after return from call to DLL).
I then tested the same DLL using the Release build of the C++ test program. The test program's assert triggered.
As far as I can tell, there appears to be an issue between the main C++ program using the MD runtime library verses using the MDd runtime library.
The C++ test program is multi-threaded using std::thread.
Has anyone run into a similar problem?
I should add that the full debug build with all runtime checks does not detect array bounds errors nor uninitialized variables, nor stack corruptions, nor calling argument errors.
Due to the appearance of a front of allocation corruption, I can only conceive that one component thinks that the debug heap is linked in while the other does not. IOW the actual allocations do not have the heap debug frames abounding the nodes, and another section plopping debug info into the missing heap debug frames. I would have expected a horrible crash and not a seemingly small memory corruption issue.
Well this is embarrassing. The actual cause was the removal of what was though to be an unnecessary zeroing of a results/working storage array under the assumption that only the valid results would be used (variable extent of these arrays used dependent upon parameters). Shame on me for not performing closer scrutiny. The peculiar thing was the error showing up with the MD libraries and not the MDd libraries. The peculiarity was apparent when running the Release build from VS IDE (release build, "Start without debugging" launch). However, when running from outside VS the error showed up in both libraries.