Debugger breakpoints not working in 2096

[klight]

Hello,

This is for 2096 (2091 had the same problem), GDB 6.3 on WinXP.

I've not had time to dig into this one, and don't know at which version it broke, but when a breakpoint is set, and the debugger is started, a message is output in the Debugger window:

Code: [Select]

No source file named C:/src/xxx/xxx.c.
Breakpoint 1 (C:/src/xxx/xxx.c:80) pending.

And the breakpoint is never hit.

I've got a snapshot at 2064 which does not have this problem.  So...

Is this a problem or just something out of whack in my configuration from previous builds?

[killerbot]

the pending means it is not yet in the loaded image, for example a breakpoint in a dll, when debugger starts it for example starting with the application _> in the application it does not find the sourcefile (since it's part of the dll), therefor pending. Once the dll is loaded and you pass in the code where your breakpoint is the debugger should halt at your breakpoint.


What I however noticed, is if you put a breakpoint, debug, you end up at the breakpoint, putting a new breakpoint (eg 2 lines lower, assuming there's code overthere ;-) ) no longer works (since 10 days or something like that)

[klight]

I finally got a chance to poke at this a bit.  The problem code is not in a dll, but rather in a multi level project tree. 

I can single step into the file, and over the breakpoint, but the breakpoint will not fire when run.  The difference is that the path of the file with the breakpoint, which is passed to gdb when the program starts, is different than the path shown between each step when single-stepping. 

The breakpoint path is the actual path of the source file.
c:\src\testproject\src\dosomething.c

The single step path is the full path, relative to the project (.cdb) file.  This relative path starts from the root, but has a "\..\" in it, which matches the path of the compiled file relative to the project.
c:\src\testproject\test\..\src\dosomething.c

I think the problem is that the debug information contains the relative path to the source file, and the debugger is passed a different path, the absolute path, which it cannot resolve.

My reason for such an odd project scheme is that I'm using C::B to develop a test suite for a cross compiled application.  The test project lives at a deeper path than the actual project.

c:\src\testproject
c:\src\testproject\src
c:\src\testproject\src\dosomething.c
c:\src\testproject\inc
c:\src\testproject\inc\dosomething.h
c:\src\testproject\test
c:\src\testproject\test\test.cbp
c:\src\testporject\test\test.c

Does this seem worthy of a bug report?  It would seem that passing the debugger the same path that the compiler used would resolve this issue.

[klight]

Fixed in 2180!

See BugReport http://developer.berlios.de/bugs/?func=detailbug&bug_id=6756&group_id=5358

and related discussion http://forums.codeblocks.org/index.php?topic=2600.0

for reference.

[klight]

While the simple nested part of the breakpoint setting problem was fixed, I still am having breakpoint issues whith "multi-project" workspaces, built and debugged as one app under one workspace.  Part of the problem is the way my projects are organized as some of the libraries are one to two folders above the main code and project in the source tree. 

Today was the breaking point for me as I really needed to debug some code from a library and couldn't because any breakpoint or "run to cursor" set in any of the library files would be completely ignored.  Stepping into the library functions would work, but my "single step" finger was developing spasms from its over-use.

What I think is the bottom line is that GDB appears to have issues executing breakpoints from full path names on files which were compiled with relative paths.

I did a quick hack to work-around debugging my current library problem:

Code: [Select]

Index: src/plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- src/plugins/debuggergdb/debuggergdb.cpp (revision 2640)
+++ src/plugins/debuggergdb/debuggergdb.cpp (working copy)
@@ -985,10 +985,12 @@
 // static
 void DebuggerGDB::ConvertToGDBFile(wxString& str)
 {
-    wxFileName fname = str;
-    str = fname.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR);
-    DebuggerGDB::ConvertToGDBDirectory(str);
-    str << fname.GetFullName();
+    //wxFileName fname = str;
+    //str = fname.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR);
+    //DebuggerGDB::ConvertToGDBDirectory(str);
+    //str << fname.GetFullName();
+    // Seems that gdb only needs the file name to break
+    str = wxFileNameFromPath(str);
 }
 
 // static

But...  The problem is that if there are two files with the same name at different locations in the project/workspace, it's a toss of the coin as to which file the breakpoint will happen in.

I think the proper solution is to use the projects relative path to the source file (as shown when viewing the file's properies) when the breakpoint is set.  This way GDB has the same source file path found in the object file.  Well, this seems like it would be the easiest solution.

I'll experiment when I have some time and file a proper report if any conclusions are reached...

[killerbot]

@Yiannis ,are you reading this ;-)

[mandrav]

@Yiannis ,are you reading this ;-)

Yes, I am

[nfz]

klight: I did the same mod back in Feb as a workaround and have kept it that way ever since.  In my app I use 6 different libs in seperate project files that I build from source which are located in directories outside the main app and sometimes have to debug into.  When using gdb on its on I found that using just the filename with out the path worked 99% of the time unless of course there were two files with the same filename ( only encountered that once and changed the file name) so made the change in CB to use just the filename.  The CB+MinGW installer that I offer for the Ogre SDK using CB + MinGW + STLPort has the same mod since I was getting complaints from users that they could not debug into external packages with the nightly builds.

Although the problem appears to be CB related it is more of a GDB problem since I can reproduce the same problem when running GDB on its own from command line.  Relative paths works from gdb command line so if done from CB would be a good workaround.