Hi,
I have a problem setting breakpoints in my code. Actually I am able to set breakpoints, but debugger does not stop when it reaches the breakpoint, it simply says "No source file named ../Safka/Safka.cpp.".
Details:
I have the following directory structure.
C:\Z
C:\Z\Saf
C:\Z\Safka
I have the following files
C:\Z\Test.workspace
C:\Z\Saf\Saf.cbp
C:\Z\Saf\Saf.cpp
C:\Z\Saf\Saf.h
C:\Z\Safka\Safka.cbp
C:\Z\Safka\Safka.cpp
C:\Z\Safka\Safka.h
Saf.cbp is a console project. Safka.cbp is a static library project. Saf.cpp contains "main" and simply calls a function in Safka.cpp which prints "doThis" on the screen. I set a preakpoint in this function in Safka.cpp and start the debug (F8). Program runs, I can see the "doThis" on the screen, however debugger does not stop on this breakpoint. On debugger(debug) pane, it says:
Setting breakpoints
Debugger name and version: GNU gdb 6.3
No source file named ../Safka/Safka.cpp.
Breakpoint 1 ("../Safka/Safka.cpp:11) pending.
Build log is as follows:
-------------- Build: debug in Safka ---------------
mingw32-g++.exe -g -ggdb -fno-default-inline -fno-inline -fno-inline-functions -finline-limit=0 -g3 -DDEBUG1 -finput-charset=latin5 -I..\K -I..\T -I..\L -IC:\MinGW\include -c Safka.cpp -o debug\Safka.o
ar.exe -rs debug\libSafka.a debug\Safka.o
ar.exe: creating debug\libSafka.a
-------------- Build: debug in Saf ---------------
mingw32-g++.exe -g -ggdb -fno-default-inline -fno-inline -fno-inline-functions -finline-limit=0 -g3 -DDEBUG1 -finput-charset=latin5 -I..\Safka -I..\T -I..\L -I..\K -IC:\MinGW\include -c Saf.cpp -o debug\Saf.o
mingw32-g++.exe -LC:\MinGW\lib -o debug\Saf.exe debug\Saf.o C:\Z\Safka\debug\libSafka.a
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
I am using "svn build rev 3202" dated Nov 10 2006, 16:32:01.
Is this a bug, or am I doing something wrong?
Thanks,
Ramazan Kartal
I have a similar project structure and the same problem (Windows, mingw, gdb-6.3-2).
I played a bit with setting breakpoints and the current directory manually (via Settings->Compiler and Debugger->Debugger settings->Debugger initialization commands (for debugging this is useless, but shows how it could work)) .
The current directory is set correctly with the directory command.
It seems that gdb does not treat a relative path given with dots (../ and similar) correctly for the breakpoint command. If I set the breakpoint with an absolute path, the "No source file named" warning doesn't occur. (Is this true too for linux/unix version of gdb?)
So, if Code::Blocks would generate the gdb breakpoint command with absolute paths, it would work. But I haven't found any setting or condition which could force CB to do this. Any suggestions?
Peter
Quote from: pbo42 on November 21, 2006, 10:38:42 AM
I played a bit with setting breakpoints and the current directory manually (via Settings->Compiler and Debugger->Debugger settings->Debugger initialization commands (for debugging this is useless, but shows how it could work)) .
:lol: "Debug->Send user command to debugger" is basically the more useful way do that!!
Entering
break "full_path_to_source_file:lineno"
there works for now, but it's not the most comfortable way...
Peter
Could codeblocks actually add all the source directories to begin with? Wouldn't that eliminate the problem? Or are the recursive paths to blame?
I'm still having the same problem with the latest nightly (3253), gdb 6.3 winXP SP2.
Adding source dir: C:\CodeBlocks\user\ytlp\gen\
Adding source dir: C:\CodeBlocks\user\ytlp\gen\
Adding source dir: C:\CodeBlocks\user\ytlp\graph\
Adding source dir: C:\CodeBlocks\user\ytlp\graph\
Adding source dir: C:\CodeBlocks\user\ytlp\aitest\
Adding source dir: C:\CodeBlocks\user\ytlp\aitest\
Changing directory to: ./bin/
Adding file: .\bin\Debug.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.3
Breakpoint 2 ("../graph/src/scenemngr.cpp:18) pending.
No source file named ../graph/src/scenemngr.cpp.
All projects are compiled with debugging symbols enabled.
Hi,
After experimenting with gdb, I found out that if:
1. You start the gdb using the command line "gdb -nx -readnow -fullname -quiet -args Program.exe"
2. You set the breakpoints for foreign files using the absolute path of filename with forward slashes
then it works.
So I downloaded all the necessary wxWidgets and codeblocks sources, changed sources accordingly and compiled. Now breakpoints work flawlessly, that is no more "No source file named blabla". I just want to test it a little more and if all goes well I will create a patch for applying to cvs sources.
Ramazan Kartal
Quote from: Ramazan Kartal on November 24, 2006, 10:35:51 AM
1. You start the gdb using the command line "gdb -nx -readnow -fullname -quiet -args
then it works.
Nice one. Please also verify that this switch is available in major GDB version (5.x and 6.x) if possible. This would be an important additional information.
With regards, Morten.
Hi,
For GDB 6.3 series, there was no problem I could find. However for GDB 5.1.1 there are some problems.
1. It does not accept "-args" in command line.
2. It does not accept "set breakpoint pending on" as a command.
3. Although it accepts "-readnow", my solution above does not work for GDB 5.1.1. It always requires an exact filename match, which you can find out by issuing an "info sources" command in debugger.
I don't have access to other versions of GDB so I cannot test them, but how many of users actually using versions other than 6.3?
Ramazan Kartal
Hi,
I just created a patch to correct the "No source file named blabla" problem, and send it to berlios.
Ramazan Kartal
Quote from: Ramazan Kartal on November 24, 2006, 04:52:28 PM
I don't have access to other versions of GDB so I cannot test them, but how many of users actually using versions other than 6.3?
Well, I've read a few times being said that debugging (in C::B) doesn't even work in earlier versions than 6.x, so I guess not many. I sure hope this'll get applied soon, as I really want to debug my libraries :P
QuoteWell, I've read a few times being said that debugging (in C::B) doesn't even work in earlier versions than 6.x
That used to be true but not anymore. gdb 5.x works fine.
Would it be possible for C::B team to post a message on this thread when Ramazan Kartal's patch will be used in a nightly build as I am in the same situation and dying to be able to debug my static lib without having to switch to VC just for that.
May I also use this message to ask how you guys deal with dependencies with your static lib ?
My app (.exe) depends on the static lib. The app project is the current one. Each time I build the app when the static lib sources have changed, the .a is generated just fine but the building of the app itself is more than random. Most of the time it says it is "uptodate" (when it's not) and doesn't link (use) the new .a
Quote from: kaylWould it be possible for C::B team to post a message on this thread when Ramazan Kartal's patch will be used in a nightly build
When it has been checked that it works as expected across most platforms.
Quote from: kaylMay I also use this message to ask how you guys deal with dependencies with your static lib ?
My app (.exe) depends on the static lib. The app project is the current one. Each time I build the app when the static lib sources have changed, the .a is generated just fine but the building of the app itself is more than random. Most of the time it says it is "uptodate" (when it's not) and doesn't link (use) the new .a
Nothing is random inside C::B (well, maybe except the $COIN and $RANDOM variables ;)).
To accomplish what you want, go to your executable target's properties, click the "External dependencies" button and add the static lib's filename there.
Hi everyone,
Thanks for the great work, CB is a really nice and powerful development tool.
The project I'm working on is also affected by the problem that is the subject of this thread (I have already written a follow-up to the bug #008949 at BerliOS with some details about that).
Ramazan Kartal's patch solves this problem using absolute paths to set the breakpoints. However it's possible, in case that it happens to be necessary, to restrict the use of absolute paths to the construction of the gdb search path.
Could you please tell me where is the apropriate place to post the details of that approach? I hope they could be useful for the development process of the debugger plugin or maybe for some other component of Code:Blocks.
Thanks in advance,
Dhionel Diaz
Quote from: diazdh on December 09, 2006, 10:47:28 PM
Ramazan Kartal's patch solves this problem using absolute paths to set the breakpoints. However it's possible, in case that it happens to be necessary, to restrict the use of absolute paths to the construction of the gdb search path.
Please notice this, too: http://forums.next.codeblocks.org/index.php?topic=4850.msg38322#msg38322
With regards, Morten.
today I update the gdb to "6.3 -2" (from 5.3)
I found the "No source file named" come back if the proejct path include a space char.
>>>>>>cb_gdb:
> break "C:/aa bb/main.cpp:7" <-- NOTE: there is a space between "aa" and "bb".
No source file named C:/aa bb/main.cpp.
Breakpoint 2 ("C:/aa bb/main.cpp:7) pending.
BUT it I create a project in a "aa_bb", the gdb work fine.
-------------------
c::b 5731
windows xp
gcc 4.2.2
gdb 6.3-2
Hi all,
I got the same problem.
I use v8.02 on Ubuntu 9.10.
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.0-ubuntu
No source file named /home/<removed>/src/test/test.cpp.
Temporary breakpoint 1 ("/home/<removed>/src/test/test.cpp:5) pending.
Program exited normally.
Debugger finished with status 0
It's a custom makefile project, created from cmake files.
I checked it and the file exists.
Any ideas?
absolutely the same here, custom makefile, file exists
c::B 8.02 (Apr 19/09)
running on ubuntu
note: "File exists" refers to the file the breakpoint is in and which gdb states it can't find, it's given in the output as a absolute path
So I guess it is likely that this is a bug in codeblocks and not in the cmake project file generator.
Correct? - If yes I will file a bug.
As mine is a self-managed makefile i would guess so, yes.
That is if i understood you correctly.
a quite short answer ;)
all i can safely identify is a error message from gdb about an non-existing file which exists in exactly that spot.
I already 777'ed the whole file structure to eliminate a error source to no avail.
I can, however, not say if this is a gdb problem or a C::B Problem, as i haven't had the time yet to probe around on the issue.
I do see the same pattern as "Eremit", though so i thought I'd second.
Some older version of gdb had problem with paths which included spaces or special characters ... If this is your case, try to move project to some "safe" path.
Path should be ok, no special characters or something like that.
Just for completeness sake as i was stumbling across this thread again:
In my case the custom make file was simply missing the -g flag to generate debug symbols which generates the "no sourcefile named" message which is pretty misleading
Quote from: fiesch on October 28, 2009, 02:48:36 PM
all i can safely identify is a error message from gdb about an non-existing file which exists in exactly that spot.
I already 777'ed the whole file structure to eliminate a error source to no avail.
I got the same behaviour when I cross - debug a PowerPC/Linux target remotely from my i686/Windows host (with C::B svn 6843). Looks like GDB doesn't like the generated "break" commands (e.g break "C:/myproject/sourcefiles/source.c:30") if the source file is not in the same directory as the project file.
I've played around a bit and the only solution I could come up was changing the command invokation to use relative filepaths (based on project.cbp), so they would look like: break "../sourcefiles/source.c:30".
This seems to be working fine in my HelloWorld - Application. I'll test it with a more complex project any time soon...
Does anyone think this could cause side effects or complications?