No Source Available Page Debugging in Parallel Studio

[rafadix08]

I am debugging a program with Parallel Studio and once the debugger enters a routine it immediately opens a page with the message:

"No source available

No symbols are loaded for any call stack frame. The source code cannot be displayed.

To investigate further, try one of these options:

Show Assembly"

This problem occurs only when I enable openmp (otherwise it rus fine), but the message appears much before I start parallelizing with openmp.

Here are the fortran options:

/nologo /debug:full /Od /heap-arrays0 /Qopenmp /warn:interfaces /module:"x64\\Debug\\\\" /object:"x64\\Debug\\\\" /Fd"x64\\Debug\\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /Qmkl:parallel /c

Here are the linker options:

/OUT:"x64\\Debug\\Retraining_RatExp.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"c:\\users\\dix-carneiro\\documents\\visual studio 2010\\Projects\\Retraining_RatExp\\Retraining_RatExp\\x64\\Debug\\Retraining_RatExp.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"c:\\users\\dix-carneiro\\documents\\visual studio 2010\\Projects\\Retraining_RatExp\\Retraining_RatExp\\x64\\Debug\\Retraining_RatExp.pdb" /SUBSYSTEM:CONSOLE /STACK:200000000 /IMPLIB:"c:\\users\\dix-carneiro\\documents\\visual studio 2010\\Projects\\Retraining_RatExp\\Retraining_RatExp\\x64\\Debug\\Retraining_RatExp.lib"

Please let me know if more information is needed.

Thanks,

Rafael

[Steven_L_Intel1]

WHen you are debugging Fortran code, you must first set a breakpoint at an executable line in your program and then press F5 or click the green "Go" arrow. If you just start by stepping, it won't work.

[rafadix08]

Yes, I am doing that.

[Steven_L_Intel1]

Please attach a screenshot of the problem.

[Geoff_Hall]

I've been searching for anyone with a similar problem to me and this fits the bill. The only difference now is that I'm using w_fcompxe_2013.4.190 as my compiler version (on a Win7 Ultimate HP notebook).

This problem only appeared recently (in the last 2-3 weeks). I thought I had cleared it the first time by reboot, clean projects (main plus dependency) and build. That "work around" does not fix it (now). I have another project (in the same solution) that does NOT show the problem, but it is NOT using any parallel coding techniques (Open-MP & MPI). (I compared the .vproj setting for VFFortranCompilerTool and VFLinkerTool to verify the differences.

I notice that this problem was first reported in 2011. Was it fixed or did it just "go away"?

So what's changed? Certainly the compiler rev, but I couldn't be sure of the project settings, which is why I looked for a project that didn't show the problem and compared project settings.

I'm fast running out of ideas of what to look for next. I'd be grateful for any assistance.

Cheers, Geoff

[Geoff_Hall]

One other thing I forgot to mention - the "No Source Code" is only on the main program. Breakpoints will stop in subroutines and display the appropriate code, but the call stack just shows the subroutine in question.

Geoff

[Steven_L_Intel1]

I don't know of anything that changed. Make sure that the current execution frame where the debugger stops is in your code, and not some library routine called from your code (perhaps compiler-generated). Look at the Call Stack frame or pulldown (depends on VS version) and make sure that the frame is set to your main program and not a library routine.

[Geoff_Hall]

OK. Knowing that it wasn't a "known" problem, I went hunting, starting with...

1. Another project still works (in the debugger correctly). (Doesn't use OpenMP.)
2. This project used to work.

So I reloaded the project (from SVN) as of a couple of months ago and tried it. It worked! So it's not the compiler, it's my project.

The major difference is that I used to have the parallel threads defined in the main program, but I moved them into a subroutine. I have two threads, defined by "section" statements. I progressively removed the parallel code definitions from the mainline - first the section definitions and then the "sections"/"end sections" statements. Still OK. When I removed the "parallel"/"end parallel" lines, that's when the debugger gave up showing the mainline source code. Is that an Intel (the compiler), Microsoft (Visual Studio), or my (the code) problem?

In other words, is it a bug in the tools somewhere, or MUST I have the "parallel"/"end parallel" lines in the mainline?

Your comments will be appreciated, Steve.

Cheers, Geoff

[Steven_L_Intel1]

The debugger doesn't have good support for threaded programs. Without seeing an example for me to try, I can't comment further.

[Geoff_Hall]

Addendum:

I left the "parallel" lines in the mainline and re-activated all the parallel code in the subroutine, minus the "parallel" lines, and the debugger shows the mainline source code at the breakpoint ok, but I've got some sort of (synchronisation?) problem in the subroutine. I'll have to look at that another day :P

Geoff

[Geoff_Hall]

Well, the wrap-up to this problem is that I have a workaround. If I place a set of "parallel"/"end parallel" lines before the subroutine call that will really do the work (i.e. these are dummies and do no work) then when the real "parallel"/"end parallel" section is encountered in the subroutines two levels down, then the debugger behaves properly and displays the mainline source code if I place breakpoints there.

The synchronisation problem I encountered was merely because I (correctly) needed the"parallel"/"end parallel" lines around the code I wanted to run in two threads.

I tried to build a little version of the problem that used the same module/calling structure to show you how the problem failed, but without the calling sequence complexity and the structures in use (I presume) the debugger was able to handle the situation correctly. (Bummer - in a sense, anyway.)

So it's all good now. Thanks for being a sounding board and pointing me in the right direction Steve.

Cheers, Geoff