11.1.048 Runtime Error

[dajum]

We have a very strange and difficult error occuring that we could use some help figuring out. We have code that we can run fine if we complile/link and run from a cmd Environment window using those environment variables. It runs fine there. But if we do the compile and link from another application, setting the PATH, INCLUDE, LIB variables to the exact same values as in the cmd prompt window it will get an access violation when it does the deallocate for an array. If I do an ALLOCATED for the array it returns true. I find I can get it to fail in the cmd environment window if I modify the PATH settings. Things like add a directory that doesn't exist to the path can cause the same runtime error. Other models can fail in other ways, usually just hanging. The bulk of the routines, including the one with the access violation during dealocation come from a library that is compiled with 9.0. But the main routine is compiled/linked with 11.1.048

I would like to submit this, but it isn't easy as the dll that does the execution has lots of coupling with the registry and needs to be installed with other applications. Separating out a smaller sample would be very difficult.

Thanks for any help.

Dave

[TimP]

I wouldn't be confident of a library built with ifort 9.0, particularly when linked with 11.1.

[dajum]

Since Intel says they should be compatible, I would just like to find the source of the problem. While I suspect it is related to memory allocation, I don't know why the environment plays any role when I have explictly set LIB, PATH and INCLUDE. How it can be different is very puzzling.

[Steven_L_Intel1]

I would guess that the program is corrupting memory somewhere, perhaps accessing through uninitialized addresses. Any variation in the run-time environment could cause stack or registers or memory to have different values. I'd be less inclined to suspect an issue with the older library, at least for now.

A simple test is to take the EXE that runs correctly in one environment, and run that exact EXE in the other environment. As it is you are changing too many things at once.

[dajum]

I guess should have mentioned that too. I did that experiment and running the same executable results in different answers when run in the cmd window. Are there other ENVIRONMENT variables that need to be set?

[bmchenry]

I am confused: you state:
>But if we do the compile and link from another application
what is the 'other application' you compile and link it from as opposed to the main application?
if you mean a test of the routine as a standalone works fine. But when linked with another application it fails on deallocate, it will depend on what the other application is you arelinking it to.
how that 'other application' handles memory and/or how the problem routine communicates with the 'main' other routine.

[dajum]

I'm speaking of the environment from which the execution of the applications occur. Executing in a cmd environment via input commands from the keyboard, as opposed to programatically executing them from within another application. You can't execute batch commands to set up the environment that the executable is running in, you have to programmatically set the environment for it. Something strange happens in that environment when it executes. I have set everything that gets set when you call IFORTVARS_ia32.bat (including the VCINSTALLDIR and VSINSTALLDIR variables), but yet it does not execute the same. I'm not sure how to figure out why they aren't the same.

[dajum]

I've found another example of the problem. I compile and link using 11.1.038 in the cmd environment. This executes fine. But open up a 11.1.048 cmd window and execute the .exe that was compiled and linked with 11.1.038 and it crashes right away during a DEALLOCATE call with an access violation. Since the violation occurs in libifcorert.dll are there some known issues with that function?

[Steven_L_Intel1]

No - what you have is a clasic symptom of a memory trasher.