User forums > Nightly builds
The 06 January 2009 build (5382) is out.
ollydbg:
I think there is a bug when debugging. (I'm using windows XP and Mingw from TDragon.
My program was linked to the debug library of opencv. which are located in:
F:\test1\lib\***
the source file is located in
F:\opencv\src\cxcore\***
It seems that I can't set break points in the source file. GDB complaints that :
--- Code: ---> break "F:/opencv/src/cxcore/cxarray.cpp:104"
No source file named F:/opencv/src/cxcore/cxarray.cpp.
Breakpoint 3 ("F:/opencv/src/cxcore/cxarray.cpp:104) pending.
>>>>>>cb_gdb:
--- End code ---
But my source file is exactly named "F:/opencv/src/cxcore/cxarray.cpp", my program will call some function in the cxarray.cpp.
Also, another problem is I can't "step into" the source code. ( This functionality is available in the last svn release).
The problem seems happens in this SVN version. The last version works well as I can remember.
I search the forum and found some related discussion.
I download the zip from the thread:
http://forums.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390
And still it can't set break point in the DLL source file.
Some one can explain it?
Thanks.
rhf:
ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.
ollydbg:
--- Quote from: rhf on January 07, 2009, 04:55:17 pm ---ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.
--- End quote ---
HI, Thanks for your hint. Actually, I already use the TDM's 4.3.2 TDM-2 2008-12-09 as you mentioned.
Maybe, it is related to the "setting break point in a header file" issue, maybe not, I'm not sure. :(
The problem seems comes from "How does the compiler and GDB handle with the path of source file".
I test the zip file from :
http://forums.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390
There are two build targets. One is a exe file. The other is a DLL file.
The exe file will load the DLL file when it runs. Both of these targets were build with Debug enabled. So, I think that in the "TestDLL.dll", there are some part to reference it's source file path.
I put the project in "C:\DebugTest"
main.cpp was located in "C:\DebugTest\TestApp"
dllmain.cpp was located in "C:\DebugTest\TestDLL"
But I can't set break point in the "dllmain.cpp".
GDB reported:
--- Code: --->>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.
--- End code ---
It is very confused that sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB. (I'm not sure how does the linker handle the path related issue).
So, I'm totally lost in this problem :(, can someone give a clarification? Thanks.
rhf:
--- Quote from: ollydbg on January 07, 2009, 05:38:32 pm ---sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB.
--- End quote ---
Interesting. I have had the same problem debugging using relative paths. I now generally use absolute paths in my Search directories, and debugging seems to work much better. This sure looks like a bug, but I haven't been able to create a simple test case to demonstrate it
Jenna:
--- Quote from: ollydbg on January 07, 2009, 05:38:32 pm ---GDB reported:
--- Code: --->>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.
--- End code ---
--- End quote ---
The gdb-message is normal for shared libraries that are not yet loaded.
The breakpoint is pending means that it's address can not (yet) be resolved.
It will be reevaluated after the lib is loaded.
It has nothing to do with the step-into issue.
If the dll and the exe are compiled with C::B make sure you have not (accidently) unchecked "Settings -> Compiler and debugger... -> Global compiler settings -> Other settings (rightmost tab) -> Advanced options... -> Others -> Use full path for source files (GDB workaround):".
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version