There is no sourcve code available

[davidgraham]

I am getting the message 'There is no source code available' when I am stepping through some simple code.

character*4 clab(500)
character*4 clabx(500)

do i=1,500
clabx(i)=clab(i)
end do

initiall I just had

clabx=clab

but that didn't work either.


If I don't step through the code I find clabx is full of rubbish.
The code is more complex than shown, the definitions are made in the winmain procedure, the code is in a subroutine that it calls.
I'm sure this code has worked for years - I'm confused.
Any suggestions?

[mecej4]

The description of the problem is far from adequate. Let me illustrate that deficiency.

If I don't step through the code I find clabx is full of rubbish

There is no indication that CLAB is defined. If CLAB and CLABX are local arrays, they have undefined values before the DO loop. Therefore, the DO loop will merely copy the "rubbish" in CLAB into CLABX.

I'm sure this code has worked for years - I'm confused.

Surely, the reason for your posting here is to seek a solution and not just to share confusion.

A complete description of the problem is necessary. Where are the arrays allocated? Are they arguments to the subroutine? How are they filled with values? Where and how do they seem to have unexpected values? Which version of the compiler was used, and which compiler options were specified?

It takes effort to construct a short, complete program with the essential ingredients -- a problem reproducer. Often, there is no hope of diagnosing and solving the problem without such a reproducer.

[davidgraham]

Sorry, I forgot to say that the array clab is filled beforehand by reading a file - it is filled with text.
I did not think it was relevant to post too much code but I should have given this information.

I don't understand the message "There is no source code available", the debug cursor is on a line of source code so I am confused to get the message "There is no source code available".
I maybe could understand it if I was calling an external routine, but I am just doing a simple assignment.

I was hoping that someone could suggest from their experiance what is a possible cause of this message.

Thanks

[jimdempseyatthecove]

You do not mention if you are debugging a Debug build or Release build. Release build will have line number association problems due to optimizations. Also in Release build "dead code" and "useless code" is eliminated. E.g. if array clabx(500) is local to the subroutine .AND. if it is not subsequentlyreferenced (i.e. you are using it as a debugging aid) then in release mode, the assignment might be eliminated entirely (although the symbol name may still be in the debug symbol table).

Jim Dempsey

[davidgraham]

I'm compiling in the Debug build.

My variables are being defined in the WinMain procedure. This then calls a subroutine 'TransferInit' to read the file and initialise the variables.

This is code that has been used for many years and I have added to, but looking at it now I can't see how the variables are transfered to the subroutine. I always assumed they were global.

I have recently upgraded the project from CVF to IVF and wonder if there is a setting that is not set.
I have just checked it on CVF and the array clabx is being assigned by the statement clab=clabx while in IVF is is not.

Hope that helps.
David

[jimdempseyatthecove]

>>My variables are being defined in the WinMain procedure. This then calls a subroutine 'TransferInit' to read the file and initialise the variables
...
but looking at it now I can't see how the variables are transfered to the subroutine. I always assumed they were global<<

If the variables (arrays) are not passed from WinMain through down all levels to the problem routine then the variables (arrays) must be

a)global (i.e. declared outside the enclosing scope of program/subroutine/function...end function/end subroutine/end program.

or

b) must have SAVE attribute and be initialized on first call into problem routine and reused on subsequent calls.

Note,some compilersdefault to SAVE while others do not.

Can you sketch your code such that we can see the placement and attributes of the variables?

Are your clab, clabx arrays

a) defined inside WinMain procedure (PROGRAM)?
b) outside scope of program/subroutine/function
c) in a COMMON?
d) if COMMON then is it named?
e) if declared insidescope of program/subroutine/functiondoes it require SAVE?

Is your WinMain C/C++, if so, then the arguments you pass via function call from WinMain to your FORTRAN subroutine(s)/function(s) may be incorrect. Verify correctness.

Jim Dempsey

[Steven_L_Intel1]

You can get the "no source code available" message if the debugger has stopped in a routine called from your code but for which there is no debugging info. Most usually this is a run-time library routine - you can look at the "Call Stack" to see where it is. In this case, the source code view will be of the first routine up the call stack that has source line info.

[davidgraham]

Jim,
Here is an outline of the code - I think I have included the important bits.
clab is COMMON but is not used anywhere else. clabx is just an array.
I think the 'contains' is supposed to make the code global.
The program runs normally correctly, I am trying to investigate a problem with different data and then the variables do not contain correct data.


integer*4 function WinMain( hInstance, hPrevInstance, lpszCmdLine, nCmdShow )

COMMON /GASH/CLAB(500),LCOD(500),CTYP(500),ISYM(500),CNUL(500),FCUSED(0:999)
character*4 clab ! moss label
character*1 ctyp, cnul ! grade type, null ht/text
integer(2) isym ! grade symbol
integer(2) lcod, fcused ! grade ftr code, feature code used

character*4 clabx(500)

! more definition
! code

call TransferInitJob(lret)

! more code

WinMain = mesg.wParam
return

contains

subroutine TransferInit(TransferReturn)

! read file to fill clab array
clabx=clab
! more code

9999 return

End Subroutine TransferInit

! other routines

end

[jimdempseyatthecove]

I seem to recall a bug associated with contained subroutines
As a work around

add CLABX(500) to your COMMON block
Place your COMMON block and type declarations into an INCLUDE file (.fi)
Then INCLUDE this include file in whatever subroutines/functions that require it
Note, the CONTAINS subroutines ought not require the INCLUDE but in the event of further problems insert the INCLUDE

Also, I suggest using implicit none


Consider using modules

MODULE GASH
character*4 :: CLAB(500)! moss label
character*1 :: CTYP(500),CNUL(500) ! grade type, null ht/text
integer(2):: ISYM(500),! grade symbol
integer(2)::LCOD(500),FCUSED(0:999)! grade ftr code, feature code used
character*4 ::clabx(500)
END MODULE GASH
...
integer*4 function WinMain( hInstance, hPrevInstance, lpszCmdLine, nCmdShow )
USE GASH
...
WinMain = mesg.wParam
return

contains

subroutine TransferInit(TransferReturn)
USE GASH ! *** this should not be required since the "host" function has the USE
...

Jim Dempsey

[davidgraham]

Jim,
Thanks, I have changed my code so that the global variables are in a module and it works OK.
I think the program was was working correcly it was when I went to look at the variables in the watch window they were not being displayed correctly.
It was OK in CVF but not in IVF. I'm not sure why that is but it is OK now and the variables are showing in the watch window correctly.
David

[jimdempseyatthecove]

David,

If it is a case of the VS watch window mucking up the display of a contains routine then try this:

Open the call stack window, double click on one level up (this should be the host of the contained subroutine), then examine the variable/array in question. I think this may be an integration issue between IVF and VS.

From your original post I thought the data was corrupt.

Jim Dempsey