Debug - no source code available for the current location

[davidspurr]

Adding to an existing program, but doing it in a new "project".

ie. set up a new project with a separate copy of the source code, then added one more subroutine in a separate file (includes quite a bit of code copied from another subroutine, but heavily modified).

Also had to change several variables in the existing code & replaced a couple of existing commons with modules, etc. Otherwise impact on the original code reasonably minor.

Now have the new project compiling, but striking problems debugging. In particular, I can set break points in the main and the new subroutine, but attempts to set break points in (at least) several of the original subroutines result in a message "There is no source code available for the current location." with an option to "Show Disassembly".

Any clues as to how I can access the source code of these subroutines so I can debug properly.

BTW - working from the IDE, with default Debug configuration AFAIK. Did nothing special. Properties for project show:

- Debug Information Format "Full"
- Optimization "Disable"

Thanks
David

[davidspurr]

Brief additional info

- I can access the source code in other "original" subroutines. Seems random to me whether or not source code is available?

- The subroutines with "unavailable" source code are being executed (well one of them at least). Can tell because the breakpoints show up in the Disassembly + I put PRINT *, 'IN SUB' type statements in the affected code & it is following the expected route through the code.

But I am keen to avoid the historical "plaster the code with print statements" debugging approach.

David

[Steven_L_Intel1]

Try a Rebuild of the solution and see what happens. Make sure that the individual files don't have custom properties to turn off debug.

[davidspurr]

Rebuild made no difference.

Strangely, I can step (F11) into the first affected subroutine, but only get down two statements before the problem hits.

Sub has multiple declarations, then the active code starts as follows (comment statements stripped):


dipLimit = 0.005
DO i = 1,5
read(10,'(a)', iostat=ios) gline
if(ios /= 0) CALL IO_ERROR('FAULT_INIT','read', gline, ios)
if(gline /= ' ') EXIT
END DO


I get down to the "DO i = 1,5" line, but attempting to execute the DO loop results in the "no source code available ..." message.

Hard to get much simpler than this. Yes all variables are declared (& IMPLICIT NONE set).

I do no get into other affected subroutines at all; ie. after pressing F11 with the pointer on the CALL statement, the pointer steps down to the next statement in the calling unit (as expected for F10).

The only deviation I can see from "recommended practice" is that the subroutine has ENTRY statements further down the page. However, the statements above are directly under the subroutine - not beneath an ENTRY statement.

One surprise to me though is that when I first step into the subroutine, the pointer (yellow indicator, or whatever it is called) first points to the last ENTRY statement, then returns to the subroutine statement on the second step - then on the next F11 (or F10), steps down to the "dipLimit = 0.005" statement.

Don't see why the ENTRY statements should be a problem - it comes from the original program & I do not recall similar problems previously.

One thought though. I developed the original program in CVF (3 - 5 yrs ago), so I may not have debugged these parts in IVF before.

David

[Steven_L_Intel1]

I'd like to see this application - please submit an issue to Intel Premier Support and attach a ZIP of your "solution", with details as to how to run the program and demonstrate the problem. Please request that it be assigned to Steve Lionel.

[ingo_berg]

Hi,

Do you use assumed size arrays as parameters to your subroutinet? If yes this is a bug in the compiler/debugger. The debugger is unable to debug routines that use assumed size arrays as parameters.

I submitted this as issue 288396

I'm quite disappointed, the IFC debugger seems to lack support for some crucial f95 features, well they may be included in the compiler but they are unusable due to false or nonexisting debugger interaction. I wonder why no one found bugs like these before. Maybe they are just using f77 code for testing.

[davidspurr]

Do not have assume size arrays in the affected subroutines, so that is not the problem in this case.

Interestingly, I changed the code at the start of one of the affected subroutines (the code sample in my original post!) & I can now access that subroutine. But the other subroutines currently causing problems (in a different file) remain inaccessible (though other subroutines in the same file are accessible).

Steve - I have taken a snapshot of the project / solution for possible later submission, but the code changes are urgent & I do not have time to document the problem at the moment.

Have made progress using write statements etc & now have most of the (first of two) tasks finished. The second will be interesting, as most of the new code will be in the subroutines still causing problems.

David

[Intel_C_Intel]

Hello.

I have seen this error message in some earlier versions of Intel Visual Fortran 8, but in the latter versions it has disappeared completely. So, if you have not installed the latest version, please try to install it, maybe this will resolve your problem?

Best regards,

Lars Petter Endresen

[yiyo2]

Hi,

I am working with visual studio 2005 and intel visual fortran 9.1.028. My OS is windows vista home premium. Rigth now,I have a problem when i try to make a debug. The debug crash when it find an instructionfor call a header file (" INCLUDE init-1.h"). Then,I recive a message "Debug - no source code available for the current location". I do not know what is happen, because the application worked fine with the las compiler (Compaq digittal fortran 6.5).

Thank you for your help