- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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?
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
...
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page