puzzling UNexplained exit

[WSinc]

I have a solution with about 22 FORTRAN source files.

Just wondering why it can exit when NONE of them are a program file, all subroutines

Its behaving as if there there is only TWO statements, as if program - - -  - END are the only two statements.

I did an exhaustive search, but there are NO program statements anywhere .

If there arent any - - -  then why would it go anywhere at all ?

Is there a way to breakpoint the FIRST executable statement with knowing where it is ?

Is there a way to delele all the object files, and have it start from scratch ?

[mecej4]

The following is a valid program:

end

If you have built a debug version successfully, F11 will launch it and stop at the first executable statement that is encountered in a subprogram that has debug symbols in the OBJ file.

You have been using Visual Studio and Intel Fortran for over a decade. This should all be under your belt by now!

[jimdempseyatthecove]

>>I have a solution...NONE of them are a program file, all subroutines

If that were true, the build process would not produce an executable.

Jim Dempsey

[WSinc]

iTS TRUE, i HAVE BEEN USING THE FORTRAN SINCE 2010.

However, I had to go back, since I cant get the more up-to-date VS and parallel studios to work.

Going to the first EXECUTABLE statement does not help, since

it does not tell me where is went.

If there are two starting points, how do I find where the they BOTH are ?

Apparently not having a PROGRAM statement in a routine can generate a starting point.

So it makes it difficult, to find where it actually IS starting.

[jimdempseyatthecove]

>>Apparently not having a PROGRAM statement in a routine can generate a starting point.

I tested this premise.

You apparently have a free-standing end statement

end   ! alone

.OR.

subroutine foo
...
end ! without or with subroutine foo
end

Jim Dempsey

[GVautier]

If you set a breakpoint in a subroutine that you know it is called, launch the debugger. When it stops on that breakpoint, the caller stack is displayed and I think that you will find the main caller at the top.

[GVautier]

Is your application a Windows application?

If so, the entry point is the winmain function isn't it?

[WSinc]

I understand the requirement to ONLY have one starting entry point.

However, finding out WHERE they are is a major challege, because of the complexity of the program.

I dont think the debugger allows me by default, to breakpoint the FIRST EXECUTABLE statement.

of coirse it wont run at all, if there is an ambiguity.

I was wondering if I could pay someone for a one-on-one consultation?

I am trouble getting around the complexities of the LATER VS and Visual parallel integration.

Seems to be an ongoing issue.

Beats waiting around for 2 days, anyway.

I think you have a priority customer assist, but not sure how to get that.

[Steve_Lionel]

If the program is a console application, the entry point is the main program (global symbol _MAIN). If it is a "Windowing Application", it is the WinMain function. Of all the things that can be difficult to locate, this is not one of them.

[GVautier]

You don't need to set a beakpoint in the first executable statement but only in a statement you know it is executed. Let the debugger go to that statement and then the stack of the calls from the entry point will be displayed.

But, as Lionel said, that's only pertinent if it is a console application. If not search the WinMain function.

An another idea may be adding a source file to your project containing an empty program statement. The linker may tell you which obj files are in conflict.

[jimdempseyatthecove]

I am not sure on Linux, but on Windows with Microsoft Visual Studio,

!  nullProgram.f90 
    subroutine foo
    end ! or   end subroutine foo
    end ! *** extra END serves as PROGRAM

from the IDE after Build (iow when program not running):

Debug | Step Into

This will break at the C Runtime Library initialization entry point.

Open the Disassembly window. At the top of that window is an Address edit box. Enter as address:

    _UNNAMED_MAIN$$

--- C:\test\nullProgram\nullProgram\nullProgram.f90 ----------------------------
!  nullProgram.f90 
    subroutine foo
00E21002  in          al,dx  
00E21003  sub         esp,28h  
00E21006  push        eax  
00E21007  push        edi  
00E21008  push        ecx  
00E21009  lea         edi,[ebp-28h]  
00E2100C  mov         ecx,0Ah  
00E21011  mov         eax,0CCCCCCCCh  
00E21016  rep stos    dword ptr es:[edi]  
00E21018  pop         ecx  
00E21019  pop         edi  
00E2101A  pop         eax  
    end ! or   end subroutine foo
00E2101B  mov         eax,0E271A0h  
00E21020  mov         edx,eax  
00E21022  mov         ecx,ebp  
00E21024  push        edx  
00E21025  push        eax  
00E21026  call        _RTC_CheckStackVars (0E23C80h)  
00E2102B  pop         eax  
00E2102C  pop         edx  
00E2102D  add         esp,28h  
00E21030  cmp         ebp,esp  
00E21032  call        _RTC_CheckEsp (0E23CE0h)  
00E21037  leave  
00E21038  ret  
    end ! *** extra END serves as PROGRAM
00E21039  push        ebp  
00E2103A  mov         ebp,esp  
00E2103C  sub         esp,2Ch  
00E2103F  push        eax  
00E21040  push        edi  
00E21041  push        ecx  
00E21042  lea         edi,[ebp-2Ch]  
00E21045  mov         ecx,0Bh  
00E2104A  mov         eax,0CCCCCCCCh  

The cursor is positioned at the line following end ! *** extra END

Jim Dempsey

[WSinc]

I unferstand about the WinMain function -

But the debugger does not allow me to set a breakpoint there.

It never appears in any source code, right ?

[GVautier]

In a console application, it must exist a main program somewhere in one source file .

[program] ! optional
...some code
end

In a windowed application, it must exist a winmain function somewhere in one source file.

integer*4 function winmain(hinstance,hprevinstance,lpszcmdline, ncmdshow )
...some code
winmain=...
end function

So you can set a breakpoint in a statement in the winmain function.

Is there external libraries or object files linked to your project? If so, the program or the winmain function may be declared in it.

[jimdempseyatthecove]

>>But the debugger does not allow me to set a breakpoint there....
>>It never appears in any source code, right ?

This is why you do not use the context of the (a) source code window to set the break point.
Instead, use the context of the Disassembly Window.

Using MS VS

Debug | Step Into | Disassembly window tab | Address: _UNNAMED_MAIN$$     or other name

.OR.

Debug | Step Into | Debug | Windows | Breakpoints | New | Function Breakpoint | Function Name: _UNNAMED_MAIN$$ | Continue

Jim Dempsey

[mecej4]

Adding to what Jim recommended: note that after starting a debug run with F11, you can bring up the Breakpoints panel by typing Ctrl-B. You can then type in MAIN__ as a function breakpoint, without having to know the name of the file wherein that symbol resides.