Debugging problem

[Pieter]

Hi all,

I think this is more of a general C++ problem than anything related to
OMNeT, but I hope I find someone here who can help me out. I have made
a project in OMNeT with an extension to MiXiM to simulate a vehicular
network, but for some reason the debugger doesn't work in this
project. If I try to debug a normal OMNeT (or MiXiM) simulation and
put breakpoints in the normal code, everything works as expected.
However, when I put a breakpoint in my own code (for example in my
extension of MiXiM's BaseDecider), the debugger just passes it. I am
really sure the line of code is executed because the console/
environment output is there. I think it is a configuration issue of
some kind.. I have built the project with gcc-debug of course. Does
anybody know of other reasons why the debugger couldn't hit the
breakpoints?

Thanks a lot!

Kind regards,
Pieter van Wijngaarden

[Andras Varga]

What is your OS exactly, and your gcc and gdb versions?

Andras

> --
> You received this message because you are subscribed to the Google
> Groups "omnetpp" group.
> To post to this group, send email to omn...@googlegroups.com.
> To unsubscribe from this group, send email to
> omnetpp+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/omnetpp?hl=en.

[Arif Amin]

I have a same problem in xMIPv6 module, I am using windows 7 and Omnet 4.1

--
Mohammed Arif Amin
Faculty IT Dept
Abu Dhabi Men's College
P. O Box 28985
Phone: 02-4048448
Fax: 02-4451571
Mobile: 971-50-6120064

[Pieter]

Mac OS X 10.6.6, and I'm using OMNeT++ 4.1 (build id 100611-4b63c38)
with MiXiM 2.1. I cannot find gcc and gdb version information anywhere
in OMNeT++, but in a terminal window

g++ -dumpversion

gives me 4.2.1, and

gdb --version

gives me 6.3.50-20050815 (Apple version gdb-1510). I think those are
used?

Pieter

[Arif Amin]

I tried to put break points and IDE comes out with an error

Sent from my iPhone

[Pieter]

In my case there is no error, the breakpoints are just skipped. I
guess that somehow gdb cannot find the code in my own project. If I
set breakpoints in classes from MiXiM itself, it works normally.. I
have compared the way MiXiM and my own code is compiled, but couldn't
find any discrepancies yet.

On Feb 1, 11:42 am, Arif Amin <marifa...@gmail.com> wrote:
> I tried to put break points and IDE comes out with an error
>
> Sent from my iPhone
>

[Pieter]

My suspicions are correct, if I run gdb in verbose mode I find this:

454-break-insert /Users/pietervanwijngaarden/Documents/Afstuderen/
omnetpp-4.1/samples/dacs/modules/phy/Decider80211FrameCapture.cc:69
454^error,msg="No source file named /Users/pietervanwijngaarden/
Documents/Afstuderen/omnetpp-4.1/samples/dacs/modules/phy/
Decider80211FrameCapture.cc."

498-break-insert Decider80211FrameCapture.cc:69
498^error,msg="No source file named Decider80211FrameCapture.cc."

The first 2 lines are written if I select the 'Use full file path to
set breakpoints' option in the Debugger tab of the Debug
configuration, the second 2 lines are when I turn this option off.

There must be something that needs to change in the compiler
configuration, I'm still searching. Any help is greatly appreciated :)

Pieter

[Pieter]

After an entire day of fiddling and a lot of frustration I finally got
it working. There are many different variables/circumstances to
consider here.

A few tips on getting it to work:

1. Do not ever, ever rename your project. It causes CDT to mess up
things internally.
(see also http://stackoverflow.com/questions/307367/eclipse-cdt-invalid-project-path)
If you already renamed your project and you experience these issues,
make a new project, copy your code from the old to the new one and
recompile.

2. If you compile your code to a shared library, the breakpoints in
those shared libraries are not always recognized automatically,
because the dll/so/dylib file is loaded at runtime. For this reason
you can configure your simulation (when debugging) to stop at the main
function, so you can, at that moment in time, set breakpoints in code
that is compiled into a shared library. I think that GDB also has
mechanisms to automatically load/initialize these breakpoints after
loading the dynamic library, but for some reason that doesn't work
with me.

My issues were actually a combination of 1 and 2, making gdb say 'No
source file named ...' to a perfectly valid file path.

I hope this information can help anybody with the same problems, if
they might ever arise.

[giorgio corbellini]

Hi all, 

I'm experiencing the same problem and I have few questions about the tips you have provided:

A few tips on getting it to work:

1. Do not ever, ever rename your project. It causes CDT to mess up
things internally.
(see also http://stackoverflow.com/questions/307367/eclipse-cdt-invalid-project-path)
If you already renamed your project and you experience these issues,
make a new project, copy your code from the old to the new one and
recompile.

ok, this is not my problem because I have the same issue even though I try do debug aloha code that was never renamed.

 

2. If you compile your code to a shared library, the breakpoints in
those shared libraries are not always recognized automatically,
because the dll/so/dylib file is loaded at runtime.

agree with you

 

For this reason
you can configure your simulation (when debugging) to stop at the main
function, so you can, at that moment in time,

 

If I understand, you say that when your simulation stops at the breakpoint in the main, you are able to set another breakpoint in your code?

 

set breakpoints in code
that is compiled into a shared library.

what else did you change? because even if I'm able to stop the simulation in the main with a breakpoint, if I try to set another breakpoint it always shows the 'unresolved breakpoint' message

I think that GDB also has
mechanisms to automatically load/initialize these breakpoints after
loading the dynamic library, but for some reason that doesn't work
with me.

My issues were actually a combination of 1 and 2, making gdb say 'No
source file named ...' to a perfectly valid file path.

to sum up: what did you do?

 

thanks, 

regards

giorgio

[jtay...@gmail.com]

Hi,

I've been suffering similar "No source file named" problems in my C++ Makefile Project when trying to debug making use of GDB under CentOs and CDT Eclipse Luna.

I've set Project Properties >> in "C/C++ Build" tab >> New Build Configuration.

Then, in "Run" >> "Debug Configurations", I've created a new "C/C++ Attach to Application" target, defining C/C++ Application,
name of project, choosing the Build Configuration I've created in the previous step, and playing up with several source locations.

I've found it strange to have only "gdb" and "gdbserver" options in the debugger combo, since I have read of "gdb/mi" searching through the web;
but, nevertheless, I've been able to debug using "gdb" option.

If I dive into the gdb logs I can see the following every time...

388,020 (gdb)
388,028 28-stack-info-depth --thread 1 11
388,057 29-break-insert -f /home/user1/project/eclipse-luna/dir/file.cpp:2437
388,172 28^done,depth="10"
388,196 (gdb)
388,196 &"No source file named /home/user1/project/eclipse-luna/dir/file.cpp.\n"
388,203 29^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending=\
"/home/user1/project/eclipse-luna/dir/file.cpp:2437",times="0",original-location="/home/use\
r1/project/eclipse-luna/dir/file.cpp:2437"}

I've followed your recommendations, but I've not got satisfying results whatever the options I've chosen. Maybe am I missing something? Thanks

El martes, 1 de febrero de 2011 17:53:47 UTC+1, Pieter escribió:

After an entire day of fiddling and a lot of frustration I finally got
it working. There are many different variables/circumstances to
consider here.

A few tips on getting it to work:

1. Do not ever, ever rename your project. It causes CDT to mess up
things internally.
(see also http://stackoverflow.com/questions/307367/eclipse-cdt-invalid-project-path)
If you already renamed your project and you experience these issues,
make a new project, copy your code from the old to the new one and
recompile.

2. If you compile your code to a shared library, the breakpoints in
those shared libraries are not always recognized automatically,

because the dll/so/dylib file is loaded at runtime. For this reason

you can configure your simulation (when debugging) to stop at the main

function, so you can, at that moment in time, set breakpoints in code
that is compiled into a shared library. I think that GDB also has

mechanisms to automatically load/initialize these breakpoints after
loading the dynamic library, but for some reason that doesn't work
with me.

My issues were actually a combination of 1 and 2, making gdb say 'No
source file named ...' to a perfectly valid file path.

[jtay...@gmail.com]

Solved!

If somebody googles by chance looking for this or similar problem, maybe he/she could find it helpful to know that, in my case, the problem was due to a "strip" command which reduced the size of the executable file,
reducing headers needed for debugging purposes as well. Once I've removed this command, I've been able to debug.

Thanks a lot!

[Rudolf Hornig]

Well, no wonder it was not working then :) "Strip" is actually for removing the debugging information from the exe file.

[Manolis]

Hey ??

+1 for adding noise to google results

1) No "strip" option is to be found around the Omnet IDE! (unless you do so from the cmd line, or ?).

2) It is not an solving the problem discussed in the thread.

I am actually facing the same issue. I get this "no source file.." message popping up every time I set breakpoint somewhere in the code which is located in some file deep in a subdirectory of the project's src/ dir. Moreover if that is the first breakpoint, the debugger does not stop there.

Symbol paths and everything are correctly set in the Eclipse CDT (to the extend possible cause somehow I cannot find the way to set explicit absolute paths).

The problem seems to be related to "delayed loading" of code and symbols ala dynamic libraries, because if I set intermediate breakpoints just in order to set incrementally subsequent breakpoints during the debugging process, i can make it to eventually pause at the points I want.

But again, I cannot find where can one set an option in the Eclipse IDE for building the code as statically linked to the omnet runtime instead of as a DLL.

Can someone more expert with this, shed a bit of true light on what is happening? Is it really that the CDT and the debugger do not speak the "same language" or share the same configuration ?

(If I ever move away from omnet to another simulator, it will be because of this damn nightmare, called Eclipse)

M.

[Rudolf Hornig]

On Thursday, 11 December 2014 01:11:49 UTC+1, Manolis wrote:

Hey ??

+1 for adding noise to google results

1) No "strip" option is to be found around the Omnet IDE! (unless you do so from the cmd line, or ?).

If you do a release build it will be automatically stripped (and speed optimized). If you are creating a debug version it will contain the necessary symbols.

 

2) It is not an solving the problem discussed in the thread.

I am actually facing the same issue. I get this "no source file.." message popping up every time I set breakpoint somewhere in the code which is located in some file deep in a subdirectory of the project's src/ dir. Moreover if that is the first breakpoint, the debugger does not stop there.

Earlier version of CDT and gdb had issues with delayed loading (i.e. setting a breakpoint inside a shared library). I had no problems with debugging recently. (but I agree that the CDT/gdb pair is the biggest pain in the whole toolchain). We are eagerly waiting whether lldb wil come alonge and save use. gdb on windows is a pain  and gdb on Mac is an even bigger problem...

What version of omnet you are using?

[Manolis]

I had an old-ish 4.3.1 ver of omnet installed on a ubuntu 12.4/vmlinuz-3.2, when the problem started. Then I moved forward to omnet 4.5, updated inet, and everything else I could think of (even binutils), but the problem is still there.

More specifically (for the record it is of any help), it does not occur in all omnet projects I have (in all of them the only dlls are INET code and NSC_TCP), but in one where under src/ i have a couple of subdirs with some c source which I am wrapping in cpp. The wrapper is directly under src/

e.g.
$project/src/*.{cpp,h,ned}
$project/src/ccn-lite/*.{c,h}

As said nothing of mine is compiled as a library (I ve not set any manual compiler option, unless there is a hidden setting somewhere).

If I set a breakpoint anywhere in the code in the subdir src/ccn-lite/, the CDT sais "all set", but gdb does not see it. If I set it from the gdb window, same effect. If I set one break point at the cpp wrapper, then the one I really want, works!!

An old version of that code (same dir structure, mostly same code overall), I was able to debug without problems on the same machine with an older tool chain and omnet 4.1 (where I wrote most of it).

tia for listening anyway

M.

[YI YU]

Just to confirm an approach to work around the "delayed loading" issue. I can start the breakpoint debug from Debug view in Eclipse.

-Yi