gdb doesn't find sources ( No source file named...)

[Azra]

I've got a problem with the gdb debugger

It tells me, that it can't find the source file, if I try to set a breakpoint

Code Select Expand

No source file named L:/CodeBlocks/Projects/Irr_02/Game.h.
Breakpoint 1 ("L:/CodeBlocks/Projects/Irr_02/Game.h:38) pending.

I've activated debugging symbols in the Compiler Options, whats the problem Oo

[Jenna]

Which gdb-version ?

Code Select Expand

gdb -v

I had a similar problem on W2K and XP with gdb 6.5.
I upgraded to 6.6 and everything is ok.

[Azra]

6.7.50.20071127

[Jenna]

I just saw that you put the breakpoint into a header file, that does not work.

[Azra]

Oh :shock:, thanks. 

But I've got one little question: why?  :?

[thomas]

I just saw that you put the breakpoint into a header file, that does not work.

Huh? I do the like all the time, why shouldn't that work?

The only thing that confirmedly doesn't work (to my knowledge) is putting breakpoints in constructors (limitation of gdb).

[nenin]

I just saw that you put the breakpoint into a header file, that does not work.

Huh? I do the like all the time, why shouldn't that work?

The only thing that confirmedly doesn't work (to my knowledge) is putting breakpoints in constructors (limitation of gdb).

It is very odd, but in some cases GDB can not find headers. It was like that, and it do not changes  for me when I move from Dev-C++ to C::B (it was main reason  ). Than I move to GDB 6, than to gcc 4, now to gcc with dwarf2... but breakpoint in some headers still are "pending". IMHO, problem is derived from directories project structure. If project has some headers in sub-directories, it is very likely than breakpoints in this files will be lost. I use defines with stub functions to catch breaks.   

[erSitzt]

I had this problem too, but with breakpoints in the cpp files and i also had problems with the debugger starting the wrong build target.

But breakpoints in the constructor are working for me.

[Jenna]

I just saw that you put the breakpoint into a header file, that does not work.

Huh? I do the like all the time, why shouldn't that work?

The only thing that confirmedly doesn't work (to my knowledge) is putting breakpoints in constructors (limitation of gdb).

You're partly right.

If the .h-file has (for example) a function in it, it works if the breakpoint is on a declaration, that is before the function or in the function itself.
But if a breakpoint is put into a header after any executable code or in a header withoutout any executable code (just declarations) you get exactly the errormessage the OP had.

By the weay I put breakpoints into my class-constructors and gdb has no problems to stop there.

[thomas]

About the constructor thing I am not sure, it may either that either the model was changed in gcc 4.x or the more recent gdb contains a kind of workaround.
The reason why breakpoints on constructors do/did not work is that gcc 3.x always emits two separate constructors, and gdb can't figure out which one to break in. So it is kind of normal, rather than a bug.

If this works for you now, then that's good news (and a sign that I should soon update my compiler/debugger).

[Belgabor]

I had this problem too, but with breakpoints in the cpp files and i also had problems with the debugger starting the wrong build target.

I also had that problem and figured out that (at last in my case) the problem was that my release and debug binary differed by " d" (and were in the same directory). The space seems to throw something off, CB reliably started my release binary claiming happily it was the debug target. As soon as I removed the space (ie just added "d" for the debug binary), everything worked as it should.

[lapique]

I have the same problem since I moved some files :
projdir\src --> projdir\..\common\src
projdir\include --> projdir\..\common\include

When I manually run gdb in a DOS shell and type "directory projdir\..\common\src" and set the same breakpoint manually, it DOES work.

So, the problem is that C::B does not actually add source directories as it should (and as it claims it does) !

[killerbot]

About the constructor thing I am not sure, it may either that either the model was changed in gcc 4.x or the more recent gdb contains a kind of workaround.
The reason why breakpoints on constructors do/did not work is that gcc 3.x always emits two separate constructors, and gdb can't figure out which one to break in. So it is kind of normal, rather than a bug.

If this works for you now, then that's good news (and a sign that I should soon update my compiler/debugger).

no idea if gcc4.x or latest gdb, but it does work for some time now : breakpoints in the constructor

[lobby]

i had the same problem, it happened after i have moved the project folder (like lapique),
i tried to rebuild many times etc... but it didn't work.

After a while, i have deleted the obj directory (containing debug and release directories for object files)
and after the rebuild, all was fixed.

I don't know exactly if that was a bug or not (i think it was), the only thing i changed in my project, is that the debug and release .exe file ouput in the same directory.

[lobby]

i tried to move headers in another folder in a "../" directory, and i get the bug back :/
deleting obj directory don't change anything that time, i really have no idea how it has been fixed the first
time.

the strange thing is that i have other projects with some includes in "../" and it works fine, maybe because i have never moved those headers since projects have been created or something like that

someone have an idea to locate/fix the bug ?