Compiler return status

[dajum]

We are checking the compiler return status when programatically executing the compiler and executable.  But have found some situations where the return status is
ifort @"C:\PROGRA~1\CULLIM~1\SINDAF~1\bin\infon.lnk"
Error - 183 status = -1073740940

But find that an executable that run fine has been produced.  This is happening when running ComposerXE-2011.

Any idea why the error message and status are returned?

TIA

[Steven_L_Intel1]

Can you provide an example that always returns a non-zero status? Note that "ifort" can cause multiple programs to be invoked (compiler, linker, etc.)

[dajum]

You mean like a sample you can run?  No that isn't possible.  Our problem is that for this one user, it always fails the first time.  The second call to the compiler always works for the same input.  The output of the compiler and linker seem fine (in that the executable produced works fine), only we don't understand why there is an error code. We get the return code and don't try and run the executable thinking it wasn't produced due to the error code. This appears to be machine specific, but in a way I don't comprehend.  Is 183 a meaningful code?

[Steven_L_Intel1]

I don't think so - but I am not sure how you are obtaining the status value or where the -1073740940 is being obtained.

[jimdempseyatthecove]

Steve,

 -1073740940 == C0000374 == ntstatus.h(8295):#define STATUS_HEAP_CORRUPTION           ((NTSTATUS)0xC0000374L)

Dajum,

Though you cannot provide the program, perhaps you can provide what is in infon.lnk from the command line.

ifort @"C:\PROGRA~1\CULLIM~1\SINDAF~1\bin\infon.lnk"

(file names, option switches, etc...)

Jim Dempsey

[dajum]

Jim,

Thanks that is very helpful.  How did you do that conversion?

I can provide the commands, but I don't think they are very helpful in that they work fine as the executable is created, it is just the status seems corrupted as your interpretation of the status code suggests.

here is the infon.lnk file

astap.for  /Qopenmp /fpe:0 /real_size:64 /integer_size:64 /names:lowercase  /iface:cref /module:"C:\PROGRA~1\CULLIM~1\SINDAF~1\mod" /MD /iface:mixed_str_len_arg /include:"C:\PROGRA~1\CULLIM~1\SINDAF~1\lib" /assume:byterecl /extend_source:132 /O3 /traceback  /INCREMENTAL:NO /link /LIBPATH:"C:\PROGRA~1\CULLIM~1\SINDAF~1\lib" "C:\PROGRA~1\CULLIM~1\SINDAF~1\lib\proces.lib" "C:\PROGRA~1\CULLIM~1\SINDAF~1\lib\utility.lib"  "C:\PROGRA~1\CULLIM~1\SINDAF~1\lib\tdsubproc.lib" "C:\PROGRA~1\CULLIM~1\SINDAF~1\lib\statwin.lib" "C:\PROGRA~1\CULLIM~1\SINDAF~1\lib\sfmatlab.lib" "C:\PROGRA~1\CULLIM~1\SINDAF~1\lib\utility.lib" "SaveSetWriter.lib"  /STACK:100000000 /MAP /MANIFEST /NODEFAULTLIB:msvcrt.lib

I'll try and show how the status is obtained once I get the piece from that code.

Dave

[dajum]

For the return code we are doing the compilation within another code. The process is launched with CreateProcess, which gives us the process id. We call GetExitCodeProcess in a loop until it no longer returns STILL_ACTIVE. If the return code is not 0 (which signals an error) we than call GetLastError to print out the error number.
sprintf(err,"Error - %ld status = %ld",GetLastError(),status);
where status is what is returned from GetExitCodeProcess

Thanks!
 

[Steven_L_Intel1]

I can't explain what you're seeing. There are too many variables. To the best of my knowledge if the compile succeeds, the exit status is 0.

[jimdempseyatthecove]

>>Thanks that is very helpful.  How did you do that conversion?

Copy  -1073740940 to clipboard, Open the Calculator, Select View | Programmers, radio Decimal, paste, Radio Hex, use the last 8 hex numbers (this is the DWORD size of the result).

... /Qopenmp ... /STACK:100000000

100MB/thread

How many threads are you running?

Are you 32-bit or 64-bit?

Jim Dempsey

[dajum]

The number of threads can vary.  Usually two, but may be as many as the machine can allow.  This is a 64 bit version (although we also have a 32 bit version).

[jimdempseyatthecove]

If the problem exhibits itself in the 64-bit version then the first thing to look at is a coding error. Compile with all the diagnostic options available (argument checking, subscript out of bounds, uninitialized variable use, etc...). If that shows nothing then...

Search your program for use of pointers, assert that they are NULLIFIED/NULLed at/immediately after declaration and after DEALLOCATE-tion. This should help track down possible errors of use of a pointer after deallocation.

If your program is mixed language (C/Fortran, ...) assert on both sides that what you see on each side is what you intend to see. Pay particular attention to strings, value/reference, optional args (or lack thereof) ...

Only after the above proves fruitless then there may be a slim, but non-zero, possibility of compiler code error.

Usually code errors will consistently fail. The peculiarity of first run fails, but subsequent runs succeeds, tends to point to something in the runtime environment. Does the Windows Event handler show anything interesting?

Jim Dempsey

[Steven_L_Intel1]

He's reporting a problem from the compile and link process, not running the application.

[jimdempseyatthecove]

Yup, I got lost in the thread... :(

The heap corruption would make me suspicious of the code generated even though it appears to run and produces correct results. Something wasn't right to get this error message.

Jim Dempsey