"No source file named" error debugging Eclipse CDT

Question

I've got a project with a shared library (loaded dynamically), and I'm attempting to debug it. I get the following error message:

No source file named /home/username/Code/path/to/project/MyFile.cpp.

After having searched other threads, I've ensured that I'm compiling with -g, and that the appropriate folders are on the source paths tab of debug configurations. The strange part is that it's giving the correct absolute path: the file it references does exist, so I don't understand why it doesn't think it's there.

Anyone know what to do about this?

Stitch

Answer 1

I just came across the same issue, although my breakpoints were in the executable itself, not in a shared library. To solve this, I had to open the "Debug configuration", select my debug configuration and adjust the following settings:

• At the bottom, there is a link "Select other ..." to select the Create Process launcher. Click the link. Tick the "Use configuration specific settings". Select "Standard Create Process Launcher" and press "Ok".
• Go to the "Debugger" tab, and on the top of the tab select "Debugger: gdb/mi". What may/may not make a difference: On the same tab there is also a checkbox "Use full file path to set breakpoints" - I played with this, but it does not seem to affect the issue we observe (obviously, our source paths are already full paths).

For breakpoints in shared libraries, you might need additional information (especially about deferred breakpoints) from Debugging with eclipse cdt and gdb and Why does eclipse cdt ignore breakpoints.

Note: This refers to Eclipse Kepler (4.3) and gdb 7.4.

Provincetown

nice answer, I think it is correct. You may also want to look at this question/.answer too: https://mcmap.net/q/359205/-how-to-runtime-debug-shared-libraries/1284631 – Jambalaya

In my case, after trying all the above steps in vain, it ended up that installing a newer version of gdb(7.4) fixed it. – Wickner

Answer 2

I had the same problem, but in my case it was my fault. Some of my projects were set to Release configuration and the debugger naturally could not find the source file information.

Chev

I had the same problem. I forgot to configure my CMake project using -DCMAKE_BUILD_TYPE=Debug. – Rambler

Answer 3

I had the same problem. I couldn't set a breakpoint in a shared library file (.so), compiled in a different place than my program. To fix this:

1. Go to the Debug Configuration, Source tab
2. Add a compilation directory (I used the location of the main makefile that compiles all processes, not where the makefile for this process is located).
3. also click "Subdirectories are also used for compilation" (my subprocess makefile is compiled in a subdirectory of the main location)

I haven't figured out how to make this change for all debug configurations future and past so that I don't have to add this directory every time, but I'll try to update later if I do figure that out.

Gulledge

Answer 4

I had the same problem but my solution was different. Open up the project "debug/src" + "release/src" directories and ensure that there are no [filename].d files that contain the name of any source files that may have changed their names or that no longer exist. I had one, deleted it, and since no more errors.

I would therefore presume, at least in my case, that the errors are created by objects that have fallen out of scope.

Setula

Answer 5

This can happen if you have both cygwin and mingw (or some other variant). If gcc from cygwin is used to compile the source you'll have cygwin path in executable. Then, if the debugger is from mingw, gdb will not be able to interpret the cygwin path. The easiest way to solve this is to go to Run -> Debug Configurations -> Debugger and set full path to cygwin gdb (C:\cygwin64\bin\gdb.exe). That solved the problem for me.

Elise

Answer 6

I followed @Andreas Fester's comment to Debugger tab in Debug Configurations settings but can't find the "Debugger: gdb/mi", but in Source tab, I removed all items and added "Absolute File Path" by click the "Add..." button at right side of the window. That helped me on this problem

Detonator

Answer 7

Thanks for all the previous tips. For me, however, none of the above suggestions helped.

In my case, the solution was very simple: compile the code once more and make sure that the files where you are placing your breakpoints are also replaced by the corresponding newly compiled files. Then stop the debugger and run the debugger again and the error messages disappear. That's all. You do not need to change anything inside the Eclipse debugger itself. My Eclipse debugger version was "Release 9.21" (Eclipse Stand-alone C/C++ GDB Graphical Debugger).

Hope this helps you too!

Equation

Answer 8

for Makefile project existing code. step 1 check compile all the sources with -g -o0 step 2 use the gdbserver and arm-yourversion-gdb which will be provided in your sdk and gdb toolchain.

Amygdala