idb problem: Cannot identify the current source file

[ivankov]

Hello,
can somebody kindly help me with the following problem concerning the usage of Intel Debugger?

I compile my program written mainly in Fortran (but also in C) with "-g -debug" and start it with idbc.
(In fact this is famous WRF weather prediction code).
I use command line, not GUI. Then I put some break points, go into some subroutines, etc. But then, when I reach some specific subroutine and try togo into it with:

(idb ) step

Then something happens. I cannot put breakpoint anymore and hence cannot debug.
When I type, for example

(idb) break 20

The message is displayed: "Cannot identify the current source file".

If I type

(idb ) cont

Then the process continues normally up to the next breakpoint which was put previously at the above level subroutines.

Thank you in advance

[Kevin_D_Intel]

I testedsome simplenested subroutine calls, module-based subroutine calls,and mixed language calls, but I cannot reproduce this with a trivial case. I tested with the latest idbc from the 11.0.083 update.

$ idbc
Intel Debugger for applications running on Intel 64, Version 11.0, Build [1.1510.2.109]


Did you receive any other diagnostics after the step command?

What does the call stack (where command) look like both before and after that step command?

That might help others look at our internal WRF builds to see if this is reproducible and if there is a work around.

[ivankov]

Thanks for reply.
Probably, I was mistaken - today I had segmentation faults, which seems, were not yesterday (I run on our institute cluster which sometimes has it's own bugs). I will test more and then will clarify the problem

[ivankov]

Well, the problems with segmentation fault were resolved, but the problem with debugging remains exactly the same as I described it in first message.

Command 'where' gives large print out

Here is the last lines of it before stepping in subroutine solve_em, where problem occur:

....
pfree = 0, dcon = 0, dpsmx = 0, tfaci = 0, xn = 0, varobs = , errf = , timeob = , nlevs_ob = , lev_in_ob = , plfo = , elevob = , rio = , rjo = , rko = }, [idb Warning: Whole array is too long to display. Only the first $maxarrlen (1024) elements are shown.]---Type to continue, or q to quit---

after stepping in:
...
pfree = 0, dcon = 0, dpsmx = 0, tfaci = 0, xn = 0, varobs = , errf = , timeob = , nlevs_ob = , lev_in_ob = , plfo = , elevob = , rio = , rjo = , rko = }, [idb Warning: Whole array is too long to display. Only the first $maxarrlen (1024) elements are shown.]---Type to continue, or q to quit---

Also 'list' commandbefore stepping in solve_em subroutineprints, as it should, 10 lines of code.

While after stepping in itprints:

"No source file named ."


I use

Intel Debugger for applications running on Intel 64, Version 11.0, Build [1.1510.2.70]

My OS is Linux Fedore release 8

[Rob_Mueller-Albrecht]

Dear customer,

can you tell me a bit more about your actual make environment? You description sounds as though you are stepping through some code where there is missing symbol line info. This could be a prebuilt shared object you link in or an OS signal handler or interrupt routine or just simply an assembly code piece that you don't have symbol info for.

Is it possible for you to identify exactly what piece of code should be executed during the stretch that the debugger isn't able to find source and then double check that you have symbol info in that piece of code.

I know this sounds unlikely., but in a slightly more complex build environment it could well be that some link step in between strips symbol info out that we need.

[ivankov]

Thanks for your help.
Finally the solution was found. It appeared that simply break worked normally in my case, though stepping in that subroutine with step command resulted in abovementioned messages.

The one more thing, that was really difficult to find was that if subroutine was defined in module I had to type
break _mp_
Anywhere in documentation I couldn't find such syntaxis of idb break command, but it was this command that worked with subroutines defined in modules.

[Rob_Mueller-Albrecht]

Sorry for not following up with you sooner. I am very glad that you found a workaround/solution for your problem.

Going back to your original issue:

break 20 wont work if there is no source correlation available for the instruction where the user stops after a step. This can happen if the application calls a temporary routine to perform symbol resolution prior to invoking the actual function, if the code was generated from inline assembly or if the routine belongs to an object which was compiled without debugging information.
Most likely however the step issue is related to some kind of shared library trampoline or address creation trampoline as mentioned above.

If the source correlation isnt available you should still be able to set breakpoints using the instruction address break *0x4001abcd, or by specifying the source file name explicitly break helloworld.f90:20.
In Fortran the standard syntax for setting a breakpoint in a subroutine that is out of the current scope but inside a specific module should be something like:

break "%"

or

break "%"

The "_mp_" in your workaround must be a result of name mangling in your application or something the like. It is not part of the standard syntax.

Just out of curiosity. Is your application built using the Intel Fortran Compiler or is it using mixed code or is it built using the GNu Fortran Compiler.?

Thanks again, Rob

[Steven_L_Intel1]

Quoting - Robert MuellerAlbrecht (Intel)

The "_mp_" in your workaround must be a result of name mangling in your application or something the like. It is not part of the standard syntax.

This is how the Fortran compiler denotes a module procedure.

[nancy]

Quoting - Steve Lionel (Intel)

This is how the Fortran compiler denotes a module procedure.

Thanks for this. I've been searching the fortran and idb docs for a long time - with no results - trying to figure out what the naming convention for this was. It doesn't help that when you do a stack traceback the entry points are listed out as "MODULE::subrname", but to set a breakpoint I had to do "break _module_mp_subrname" - all lower case, leading underscore, _mp_ in the middle. I'm using straight ifort - no gcc/gfortran involved here - with -g, no flags to change cases of anything, and starting idb in whatever the default input syntax is (dbx? gdb? i've used both for so long that if 'stop in' doesn't work, i try 'break' and move on).

I have to say the documentation for how the debugger works with fortran has been very frustrating. I couldn't find the simplest basics for how the fortran naming conventions and scoping levels are handled, like for printing a module variable, or listing a subroutine from another file, etc. Even something as basic as trying to stop at the program entry point seems to be "break program_name" (e.g. if your executable is called 'foo', you have to do "break foo" -- not "break main" or any convolution of that). I still can't figure out how to print public module variables. I found some documentation which claimed that "print 'modname'varname" was the syntax, but no dice. (nor mod%var, nor `mod`var, ...) Anyone got a hint on that one? (ifort version 11.1, mac os 10.5)

thanks,
nancy