Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
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: ---No source file named C:/src/xxx/xxx.c.
Breakpoint 1 (C:/src/xxx/xxx.c:80) pending.
--- End code ---
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: ---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
--- End code ---
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...
Navigation
[0] Message Index
[#] Next page
Go to full version