No debug info for part of a source file

[davidspurr]

I have a moderate size project that contains a number of source files (all .f90).  One of those consists of a 'main' subroutine and a number of CONTAINed subroutines.

Since I had XE2011 installed, I encountered problem debugging the 'main' subroutine; eg. if I put break points in the 'main' part, or if I enter the 'main' part (via 'F11' from the line of code in another source file that calls the 'main' part), the compiler opens a separate tab say that debug info cannot be displayed.  The problem is only occuring in the 'main' part of the subroutine.  Source code for all the CONTAINed subroutines displays normally; 

The code still runs OK and I can continue on to other parts of the program, including the internal subroutines of the 'main' part, without problem (source code displays OK). eg. 

   source1.f90 includes a call to 'main_sub'.

   source2.f90 includes subroutine 'main_sub', which CONTAINS say 'int_sub1', 'int_sub2', 'int_sub3',etc

In debug mode, I run to a breakpoint on the line in source1.f90 that calls 'main_sub' > debugs normally (displays the source code)

Press F5 and move to a breakpoint in 'main_sub' > no source code displayed, opens tab saying that debug info not available (or words to similar effect - cannot check actual message now since compiler is currently 'broken' - other post).

Press F5 again and move to a breakpoint in say  'int_sub1' > debugs normally. Ditto for anywhere else in the program (except the main part of 'main_sub').

Program runs 'OK' in both debug and release mode, but following changes made a while back, there appears to be an error in the results produced (new code does not produce the same results as a version from a couple of years ago.  Should be the same).  Unfortunately, one of the suspect parts is in the part of the code that does not debug properly, making it very difficult to track down the problem.

The debug issue is 'relatively new' (last year or two - do not recall when first encountered).  Certainly has been there since I had XE2011 ver8 installed & possibly before then - probably since XE2011 first installed. 

Before posting here I decided I better update to the latest compiler (2013 ver3) but as posted elsewhere, it made no difference to this problem (& I subsequently appear to have broken the compiler by uninstalling 2011 ver8.

[DavidWhite]

What you describe suggests that the main_sub you are putting the break points in is not the same copy that is being used in your build.  This would produce both the effects of giving different results, and the break points not being hit.  "cleaning" the solution and rebuilding everything may be a start.

Regards,

David

[mecej4]

Davidspurr:  In addition to David White's advice, consider the following.

Your description is insufficient to reproduce the problem: the two files attached fit your description of your source files, but everything works normally when the EXE is compiled with /Zi with the 12.1 or the 13.1 compiler.

Short of duplicating your steps (including those that you did not describe) or replicating your damaged compiler installation, I do not see how one can reproduce the problems that you described.

[davidspurr]

Have tried that. 

Also, the fact that breakpoints further down in the same source file (ie. in the CONTAINed routines) debug OK would seem to rule out the possibility of the breakpoints not being in the same code. 

For what it is worth, this problem is occurring on my main PC, which is getting a little long in the tooth - late 2007 vintage if I recall correctly (hence lack of disk space on C:).  OS is Vista64 (which I normally have no problems with, despite its 'reputation').

Several weeks ago I did discover that two versions of the 'problem' source file had got caught up in my project.  I removed the old version and did a full rebuild but still the problem persists.  As a further check on that being an issue, I placed a copy of the entire source code for the project (minus the offending old version of the 'problem' source file) into a new directory and created a new solution from scratch.  But the problem still persists :(.

But ... I just checked and found that the problem does not occur on my laptop (same code).  Had not checked that as I normally only use the laptop when travelling.  It is a ~1yr old Viao S series laptop with Win7 OS and 'plenty' of disk space (>100GB spare).  Compiler on that is still XE2011 (vers8, I think)

[davidspurr]

Note - my reply was to David White.  Merecj4's post come in while I was typing.

[DavidWhite]

David,

Your symptoms still seem to relate to having multiple source files.  That the breakpoints work in parts of the file and not others suggests that by conincidence these lines work, while the others have no corresponding locations in the exe file.

You may need to check the project files, and the build log to see which files are getting included into the project.  Manually removing all of the object and mod files, particularly any generated interface modules, may help ensure that the build includes all of your latest code.  It is possible that one or more files have not been rebuilt, and the debugger is using the references for that file which do not match the current source, hence the missed break points.

Regards, David

[jimdempseyatthecove]

David,

Try the following:

Remove the break points in main_sub
Place a break point in Source1 at "call main_sub".
Run to that break point.
Press F11 (or Debug | Step Into)

Do you arrive in main_sub?
If so, is the entry at a statement or comment/open line?
If comment/open line then the line number information in the .exe for routine is incorrect (possibly old build from prior version, therefor Clean and Rebuild). If at statement then then press F10 (Step) to see if follows program or steps to comment/open line or step seems to not follow source listing. If odd behavior then possibly old build from prior version, therefor Clean and Rebuild.

Jim Dempsey

[davidspurr]

PROBLEM NOW RESOLVED (after unintalling & reinstalling 2013.3). 

It seems I should have uninstalled all previous versions before installing 2013.3 (I in fact had three older versions still installed!).  I have always been reluctant to uninstall earlier versions until I know that the new version is working.  Then once all is working, the imperative to go back and uninstall dissipates (compounded by concerns that subsequent uninstalling could cause problems - as indeed occurred).

However, it seems that the problem I was having was a carryover from an earlier version (possibly v10?); ie. problem carried over into 2011 and then into 2013.  That could explain why it did not occur on the laptop, since 2011 is the first install of the compiler on that machine.

Although the release notes indicate that older and newer versions can happily co-exist, based on my recent experiences it seems preferable to uninstall an older version before installing an update?

Or possibly just freeing up space on C: by removing all the old installs made the difference (now have over 3.5GB free). That seems unlikely though?

=====
Thanks for the suggestion, Jim.

I had already tried that (several times!).  Ie. Break point on the call in Source1, then Press F11.  However, on pressing F11 the compiler immediately openned a separate tab say that debug info cannot be displayed.  I could still continue on through the code (F5, F5 passed a couple of break points in the problem sub), until emerging into an internal sub where debugger behaved normally (ie. could view & debug the source code).

Sorry, I did not mention this initially as the description already seemed complicated enough.

Anyway, as noted above, the problem appears to have been a carryover from and earlier version of the compilier.  Has now 'resolved itself'

Thanks to all those who offerred help