I am working on modifying a rather large program (NS2 network simulator), and it would be nice to be able to debug it with Eclipse. I configured the makefiles ( add -g to CFLAGS ) to make gcc generate the debugging symbols, and they are indeed generated, but Eclipse refuses to actually find the code associated with those symbols. I imported the HUGE folder of source code using the "Makefile Project with Existing Code", and when I hit "debug" it runs the program. When I tell the debugger to stop, it often stops in a method I recognize, but when i click on the method's name, it says "source not available" even though the source file where the method is defined is actually open in another tab. I do have all the sources imported into the project. Am I missing something in the make configuration?
^long confusing explanation, I know... see screenshot, :
http://imageshack.us/photo/my-images/651/zzz1fu.jpg/
Note that IPKTAgent::deBurst() from the above screenshot is declared in integrated_agent.h -- that is the file I have open in the other tab.
also, when I expand the entry for the executable I'm debugging in the project explorer, it only lists some of the files it is composed of. What gives? (see screenshot, there should be more files on the list, the ones I'm working with are missing).
screenshot: http://imageshack.us/photo/my-images/96/zzz2z.jpg/
Just tested it. Works for me. The only issue was that I forgot to add -O0 option to disable optimization; it can be an issue in your case too.
What I can suggest:
Try to disable optimization
Check that compiler options you use are really applied. You use CFLAGS, but I see c++ in tags, so it is possible that you should use CXXFLAGS (it can depend on build tools you use)
IPKTAgent::deBurst() is declared in integrated_agent.h. But where is it implemented? Check that it is implemented in header and/or you can access to the source file where it is implemented.
Check that you can debug your executable with gdb
Try to create simple automake/autoconf based project and check that you are able debug it in gdb and eclipse. You should be able.
Related
I am new to eclipse cdt. I did a little research but did not find an answer. I wonder, say I have a project/simpleClient/simpleClient.cc that calls functions under project/src/somefile.cc. When I put a debugger in simpleClient.cc, and call function A, I only know by right clicking the function name will take me to the function definition, but I actually want to step into it to the src folder code and see how the program runs. Are there any ways please?
Thank you.
Under Run -> Debug Configurations -> [Your debug config], click the Source tab and see if the project and all associated subdirectories are in the source search path.
That's how Eclipse CDT tools find the sources to display while debugging, so chances are, the file is not being found on this path.
I think by default, the tool searches the project directory for all sources, so something else is likely preventing it from being found.
Also, if you're running in Windows, using Cygwin, you might have the problem described here. If so, the instructions provided should fix the mapping and let you see your sources.
When debugging a C++ Project using Visual Studio 2010, it cannot find the source for crt. When I am trying to go inside one such module, it displays "No Source Available". It also does not provide an option to Browse so that I can help it locate the source location.
Under the Option Solution->Common Properties->Debug Source Files, the proper location to the crt source is updated.
In lack of source level debugging of crt I have to read through the disassemble which is getting difficult.
Can anyone help me figure out what might be going wrong?
Please Note ** I am using an external build system via Visual Studio to build my C++ Project.
With the guidance of Hans here how I narrowed down to the problem.
While the breakpoint was still active, I listed all the Symbol Load information. I realized that msvcr100d.i386.pdb did not match the dll. It actually went all the way down to fetch from the microsoft public symbol store which off course had the symbols stripped off. So that was the root cause of my problem.
And here is a similar problem in social.msdn
You can see the cause of the problem by using Debug + Windows + Modules while you have a break active. Right-click msvcr100d.dll and select "Symbol Load Information" to get info about the .pdb that the debugger uses.
For some reason the Microsoft Symbol Server supplies one that has the source info stripped. It is probably intentional, something to do with service and security patches of the DLL getting out of sync with the source code in vc/crt/scr. You can get a real answer instead of a guess by posting to connect.microsoft.com
A workaround of sorts is to compile your code with /MTd instead of /MDd, if that's possible at all. Project + Properties, C/C++, Code Generation, Runtime Library setting. The debugger will then use the .pdb file in vc/lib. Do keep your eyes on the ball, debug your code instead of the CRT's.
You can find the sources for the CRT in your installation folder, subfolder VC\CRT\SRC.
If they're not there, did you install them when installing VS2010? (not sure whether you can really choose this).
I am having some trouble debugging a visual studio 2008 C++ project. When I start running it in debug, the breakpoints are disabled with the message
The Breakpoint will not be hit. No Symbols have been loaded for this
document.
I have tried cleaning and rebuilding, but this doesn't make a difference.
I also tried looking in Debug->Windows->Modules. If I right click on the module I am trying to debug and press Symbol load information it brings up a list of places it has tried to load the symbols from. The first in the list is correct and the file exists, but next to it is this error
C:\path\to\my\symbol\Debug\MyProject.pdb: Unknown symbol handler for
error
Does anyone know what causes this or how to fix it?
First of all, it is possible that some of your modules won't show in the module window, because some of them may be loaded dynamically (only as needed).
You might want to check in your project properties under Linker > Debugging > Generate Program Database File and Generate Debug Info. Be sure these two are set properly.
Also, check if C/C++ > General > Debug Information Format is set to Program Database for Edit And Continue (/ZI) or something similar.
I know you mentioned that your symbol file exists, but checking what I just mentioned will ensure you have the right version of your symbol in the right place.
Finally, check if all your project and files in your solution are set to compile as Debug and not Release or something else, because no symbols will be generated (hence none will be loaded) for this project / file.
Hope this helps a bit.
In my case, the problem was solved by checking "Use Managed Compatibility Mode" in Tools / Options / Debugging / General.
In case anyone has this problem when using 'Attach to process', the answer to this question solved it for me:
Visual Studio is not loading modules when attaching to process
Specifically, switching to 'Native code' in the 'Attach to' options instead of 'Auto'.
I have managed to solve this by copying my source sideways and checking out a completely clean copy. I assume it was some setting stored in the projects .suo file.
Go to the "Properties" for the website that would use that dll for debugging and then select "Native Code" in the "Debuggers" section below:
There could be a problem with the mspdbsrv.exe process. Try killing it and start debugger again.
For me the fix was in restarting the Visual Studio :) As simple as that. Nothing else helped - tried to Clean (even deleted all files in the Debug folder), checked settings, even killed the mspdbsrv.exe process, but only VS restart did the trick.
In the Modules window you can right click and add your Debug output folder to folders where your system looks for symbol files. Also, the thing that worked for me was deleting all the output files manually, Clean won't do it every time and that's why even though the .pdb file is generated, it doesn't correspond to your output files, thus not loading symbols from it.
Delete all files in the bin and obj folders. Then build the solution again. If your problem was like mine, it seemed like VS was loading an older version of a specific unknown file that rebuilding the solution/project would not replace. Make sure to make a copy of your solution/project before trying this. Good Luck!
Make a copy of your "Debug" folder within your project's folder, then delete every file in the original "Debug" folder. As additional measure if you had your visual studio already running with your project loaded, close it after deleting Debug's contain and reopen it before re-build the whole project, theoretically this action will create new copy of symbol files and the rest needed to debug your code.
I found out this problem occurred to me when I moved my files to other computer and try to compile and debug my code from there, although all folder and drive names were the same, some how the IDE was unable to use the previously created symbol files.
Hope this work around works for some one else !.
VS2015 C++
I ran into the same problem after cancelling the loading of symbols whilst attempting to debug my application in VS2015. After this, VS2015 refused to load the symbols for the project I was interested in (multiple sub projects in a solution with C# calling C++ DLLs). Solutions above did not work for me, but this did.
For Visual Studio 2015 (C++):
Right click on your project that your break point is in and select
properties Expand C/C++
Select General under C/C++
Change the Debug Information Format to any other option
Click Apply
Change the Debug Information Format back to its default "Program
Database for Edit And Continue (/ZI) (or whatever you prefer)
Click Apply
Now rebuild your project
Hope this helps.
Alan M
1) Right click on the project you want to debug.
2) Select [Properties]
3) Select the [Build] tab
4) Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
5) Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
6) Click [OK]
7) Rebuild the project
In my case, "use library dependency inputs" in "linker->general"should be set to yes, then the problem is solved.
None of the above helped me...
At the end I changed from Debug\X64 to Debug\win32, this helped, probably it's some configuration which isn't the same in both. Maybe this will help as a
workaround for someone...
Hope that could help anyone.
I'm debugging a WIA driver, and came across this similar problem.
I noticed this log :
DLL named C:\Windows\System32\WIA\wiadriverex.dll cannot be loaded (LoadLibraryEx returned 0x0000007E). Make sure the driver is installed correctly
Then I realized that it is due to DLL dependency. Then I copied required DLLs to System32, the problem is gone. Pay attention, copy to System32, or it won't work for me.
It helped in my case:
Debug -> Attach to process
Scroll down to w3wp.exe
Check "Show processes from all users
After refresh scroll again to w3wp.exe
Select new one with type x64, Managed (Native compilation)
Try disabling /GL option if it has been enabled in C/C++ / General / Optimization / Whole program optimization.
Initially, I had no issue with debugging my program but after tweaking here and there the issue that OP says began to arise.
The module and its symbols were loaded and nothing in this guide seemed to correspond to my problem. Turning /Zi to /Zl also didn't help.
I'm not sure why, but, it's sort of a compiler behavior I haven't been experienced before. FYI, /GL option is not a default in the C++ projects in VS2017.
In my case, the error was due to the fact that part of the code was connected as an external library. In order for debug process to work also when going into the code of the external library, it was necessary to add not only its headers, but also the implementation files - folder Source Files of Solution Explorer.
In my case it was debugger type.
I used remote windows debugger, changing it to local solved an issue.
Debugger options:
I'm having trouble debugging a C++ program in Eclipse (the latest RC of Helios, updated with latest CDT from within itself) on OSX.
The program is very simple (esentially Lesson 2 from NeHe's OpenGL tutorials), consisting of one cpp file and, using OpenGL and Cocoa frameworks, and linking with libSDL.a and libSDLmain.a.
The structure of the project is very simple: the source file(s) are in a subdirectory of the project called src/ and the executable is built to the project's root directory.
The problem is that whenever I try to add breakpoints and debug it, the breakpoints seem to get hit perfectly but no source is displayed - instead I just get a "No source available for main()" error in the code window.
The compiler flags have optimisations set to none, and both the compiler and linker have the debug symbols flag set (-g).
The debugging setting in Eclipse is set to "Standard spawn progess" and the debugger is set to "gdb".
Now the strangest thing is that if I try to debug the exact same executable - ie. the exact same one that was built by Eclipse - using gdb from the Terminal (shell) then everything works fine. Breakpoints are hit, source code is displayed, no problems at all.
I've made sure that both Eclipse and the shell are using the same gdb executable, and they are (it's /usr/bin/gdb).
Now I may be wrong, but this all suggests to me that there can't be a problem with the compiler and linker flags (because the same executable is debuggable from the shell), so presumably the problem must be with how gdb is being invoked from within Eclipse? Perhaps when run from Eclipse gdb is picking up different config files or something than when it's run from the shell? (Anyone know?)
I'd really appreciate any help with this because it's slowly driving me loopy!
Please let me know if there are any other details that would be useful - exact version numbers of Eclipse/cdt/gdb, exact linker/compiler command lines, etc. - and I'll very gladly update this post with them.
Many thanks in advance,
thoughton.
--- edited # "14 hours ago" ---
I tried the "add filesystem path" (with "search sub-folders") option, but that didn't work. I also tried creating a new completely flat project, but that didn't work either.
I even tried getting a Galileo release (eclipse-SDK-3.5.2RC4 with CDT update), but that made no difference (apart from gdb being slower to launch).
And here's something else strange I noticed: once I get the "No source available" message, if I then switch Eclipse's Console to display the "gdb" console, and also turn on "Verbose console mode" so I can communicate it, I can then issue "l" and "bt" commands and have them work succesfully, showing the correct source and stack where my breakpoint was hit. Which, correct me if I'm wrong, must mean that the information is there and gdb is being invoked correctly - so why will Eclipse not see this information?
I'm getting close to giving up on Eclipse to be honest... I came to it with such high hopes, too.
Any additional help or thoughts would be hugely appreciated.
t.
This thread suggests:
-g -O0
for debug flags to be set for Eclipse CDT compilation.
Sometime, it is simple a problem of rebuilding completely the application (like here)
See also this thread describing a similar situation:
I have noticed that sometimes in Eclipse I have to go and specifically add the path to my source files using the "add filesystem path" (with "search sub-folders") in the Debug Dialog (even when they are in the same project I am debugging), but I have not noticed a pattern to when I have to do this. But it may be worth a try.
I found the answer! And it's embarrassingly simple.
The problem was that I was using the Release version of SDL instead of the Debug version! (I had 'libsdl' from MacPorts whereas I should have had 'libsdl-devel'.)
So my generic answer is: make sure the libs you're linking against were compiled with debug flags set too, it's not always enough to just make sure your own code has them set.
Here is another reason for this problem. My configuration used -g3 as the option to gcc. Changing it to -g solved the problem. There seems to be some incompatibility between gcc and gdb. I checked that gdb was the latest revision (using apt-get).
I would like to add a little new blood to this old thread.
I encountered this problem when I tried to compile and debug a gnu arm project.
I solved the problem by modifying the Makefile:
adding "-g -O0" at the end of this line "CFLAGS += -Wall -Werror -O3"
Go to project Properties, C/C++ Build -> Settings. On the first tab (Tool Settings) under Cross GCC Compiler click Debugging and set Debug Level to Maximum (-g3)
I had this issue when I compiled the latest gcc, but did not update to the most recent gdb. After the update, it worked properly.
Thought to mention, that in case you are using cmake to build the project, one approach to the solution will be to add the "debug flag" to the cmake command, i.e. -
$ cmake /path/to/main/cmake_file -DCMAKE_BUILD_TYPE=Debug
For anyone else who may experience this issue,
I installed the linuxtools/valgrind plugin last night to do some memory profiling, and it seems that this broke the normal gdb. when i removed the linuxtools plugins everything started working as normal again.
So you might like to try that.
I had a similar problem. I was using CFLAGS=-Wall -O2 -fPIC -DPIC -lm -lasound and never had problem to compile it but when I tried to debbug it on Eclipse IDE I get this error: No source available for "main() at 0x401080" then I added -g to this line and it worked well:
CFLAGS=-g -Wall -O2 -fPIC -DPIC -lm -lasound
This issue depends on how gdb is being invoked. I found I needed to manually specify the source file locations when I got that error. Even though I'd already configured that under project properties. After doing so, Eclipse no longer had a problem supplying the appropriate source.
Using the release versus debug version of a library may be your specific problem (if you were building a library from source then debugging it). If someone is using a precompiled library, they'd never be able to set breakpoints within it and so that fix wouldn't apply to them.
Encountered the same problem once. You just have to go to your Project Properties, by hitting ALT+ENTR or right click project and scroll down at the bottom and you will find Properties. Expand C/C++ build on the left. Then click on settings. Once you open the settings, then click on tool settings. In the MCU GCC Compiler, there is a debugging option. Click on debugging and add
-g -O0
in the Other debugging flags. Trying debugging the project now.
I just faced with this issue and after take some time to find it out, I realize that the Arguments and Main tab in Debug Configurations dialog are conflicting each other.
Make sure that C/C++ Application and Programs Arguments point to the same binary file.
Seems like this message can have plenty of reasons to show.
For me (in the context of micro controller debugging) it was the link-time optimization. With -flto it broke; removing -flto from the "Other Options" field fixed this for me.
In Eclipse Neon (4.6) see Project -> Properties -> C/C++ Build -> Settings -> Tool Settings -> C Compiler -> Miscellaneous -> Other options.
Add this to your CMakeLists.txt
set(CMAKE_BUILD_TYPE "Debug")
set(CMAKE_CXX_FLAGS "-g")
set(CMAKE_C_FLAGS "-g")
Using visual studio 2008 SP1,
This line:
LINK : debug\XXXXX.exe not found or not built by the last incremental link; performing full link
appears every single time I compile the project, no matter how small a change I make.
What could be the reasons for that?
Old question, but just in case for someone it is still an issue (and it is..).
Incremental link is incompatible with generating manifest file (Proj opts > Linker > Manifest File > Generate Manifest: Yes). Indeed, generating manifest modifies exe/dll so linker has to do full linkage.
There are some workarounds, for more details:
http://chadaustin.me/2009/05/incremental-linking-and-embedded-manifests/
Temporary (and easiest/fastest) solution is to disable manifest generation during development and enable it again in the release stage. Although this disables XP/Vista-style gui for the app (controls look like in "classic mode").
So it turns out that the problem fixes it self if I add /INCREMENTAL to the linker command line. This in spite the fact that the default behavior according to the docs is to enable incremental linking.
Strange.
Really shooting in the dark but,...
Do you move the XXXXX.exe from where it is built to somewhere else? The whole point of an incremental link is to change an existing exe. If there is none, it will be difficult...
Another possible reason is that the file was changed after the build (probably by another tool)...
All the reasons are listed in the help item for /INCREMENTAL:
Additionally, LINK performs a full
link if any of the following
situations occur:
The incremental status (.ilk) file is
missing. (LINK creates a new .ilk file
in preparation for subsequent
incremental linking.)
There is no write permission for the
.ilk file. (LINK ignores the .ilk file
and links nonincrementally.)
The .exe or .dll output file is
missing.
The timestamp of the .ilk, .exe, or
.dll is changed.
A LINK option is changed. Most LINK
options, when changed between builds,
cause a full link.
An object (.obj) file is added or
omitted.
An object that was compiled with the
/Yu /Z7 option is changed.
Download procmon from Microsoft.
Run it, set up a filter so that you are looking for accesses to the path that contains your .exe name.
Do a link.
See what trouble it's having -- does it find it, does it log an error on opening it. Procmon will log every single file open, read, close, etc. If it gets an error, it will log it.
Also make sure it can find the .ilk file -- I think it needs that as well.
(ALso in the dark) One possible reason is that you use a project-wide header referencing the __DATE__ macro. But in that case, you'd see a full recompile as well (do you?)
In my case, I have got this error yesterday.
VS set code generation > runtime Library to Multi-threaded Debug DLL (/MDd) instead of Multi-threaded Debug (/MTd).
If i recreate new project this bad settings happens again. I manually switch to /Mtd, then no error happens.