Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Verifying a stop-code

Ted_Lillys
Novice
387 Views

I have a console application called by a C# UI.  I would like to use

STOP stop-code

to communicate stopping conditions of the console app to the UI. 

I assumed that testing in VS would show the value of "stop-code" in the VS Output window like:

The program '[7408] TEST.exe' has exited with code 0 (0x0).

However, if I force the application to exit with

STOP -1

the output in VS Output window does not change. So I'm guessing my assumption is incorrect.

How do I verify that the application is returning a specific stop-code in VS?

TIA 

Ted

Windows 10

Visual Studio Community 2019

Intel Fortran Compiler 2024.0

Labels (1)
0 Kudos
4 Replies
andrew_4619
Honored Contributor III
346 Views

Well the stop code is written to the application console window but in VS debug the console window is closed the moment the application ends so you never see it. If you run the app in a cmd window you see the exit code which may also connect to the cmd variable %errorlevel% but I have not tested that.

0 Kudos
jimdempseyatthecove
Honored Contributor III
322 Views

Try inserting

 

PAUSE "We are stopping because of bla bla bla"

in front of the STOP(s)

 

What I prefer to do is to write a subroutine named DOSTOP

And call that

if(SomeErrorCondition) call DOSTOP("SourceFile - SomeErrorCondition")

...

RECURSIVE SUBROUTINE DOSTOP(CVAR)
    USE IFPORT
	USE MOD_HOST
    implicit none

    CHARACTER*(*) CVAR
    logical, volatile :: escape = .false.
! place break point here
    WRITE(HOST%IOUERR,*) CVAR
    WRITE(*,*) CVAR
    do while(.not. escape)
        call sleepqq(100)
    end do
    print *, "Stepping out of DOSTOP"
    RETURN
    END

(edit the above for your own purposes)

 

Make a configuration, (e.g. DebugFast), that is based on the Debug configuration, but then set all the Projects Optimizations to whatever optimization level you desire.

The above procedure is compiled without optimizations and with full debug information.

Now you have Release code with DOSTOP compiled as Debug build

Run the Release build in the Debugger .OR. run it as usual from CMD or File Explorer

If an error occurs, you will see the message, and have more of an informative message than an error code. You will know where the error occurred and what was the reason.

 

If you ran from CMD, then from/launch MS VS you can Debug | Attach to Process then issue the break. Go up the stack level to the DOSTOP procedure, place a break on the sleepqq, then Continue (to the break).

Depending on your circumstances, you may wish to step out of DOSTOP, to examine the cause of the error. To step out, you can use the "Set next statement" to position after the do loop. Then issue step or step out.

 

*** However, the 1st time this happens, the caller's source file was compiled with full optimizations, and is not friendly for debugging.

When you cannot make sense of the cause, modify your configuration to remove optimizations from the offending file.

On the next run, and error, if in same source, you can step out and have full debug info for the offending source.

 

Jim Dempsey

0 Kudos
Ted_Lillys
Novice
298 Views

Thanks for the replies.  Allow me to rephrase - And perhaps I need to ask to a different forum.

I'm running a Fortran Program using the Process class in C#. I'd like to send a return code back to C# using the Process.ExitCode property. I "assumed" (always bad) that what was displayed in the VS Output window was equivalent to what was returned by program. Clearly that wasn't the case.

My question is how to test if the stop-code is propagated back to the Process object or if I need to approach this in some other fashion. 

 

0 Kudos
Steve_Lionel
Honored Contributor III
272 Views

The standard says, "If the stop-code is an integer, it is recommended that the value be used as the process exit status, if the processor supports that concept." Pretty much all the compilers I know of support this. So, when your C# program runs the Fortran program, probably through CreateProcess (since you're using Windows), the C# code can request the process exit status using the Windows API. I'm gathering that the display of the value in the terminal is of lesser interest. Do note that if you run the program from outside VS, you'll see the stop code message in the standard console window. You can now also suppress that message with QUIET= if desired.

0 Kudos
Reply