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.
So I am building some Arduino code in eclipse, as described in Your Second Arduino Project, but every time I use an Arduino library, such as Serial, Eclipse underlines my function names, claiming they cannot be resolved. However, the code actually compiles, so I'm kind of at a loss as to why Eclipse thinks the functions are missing. If anyone has any idea on how to solve this problem it would be appreciated. Thanks beforehand.
EDIT: I should have been more specific, Eclipse underlines the METHODS inside the Arduino libraries. So if I use Serial.println("hello");, it underlines println() and claims it cannot be resolved. Then it compiles just fine and the method works when uploaded to the arduino board.
EDIT2: I found my error, turns out I was trying to use some C++ functions in a C file, and eclipse didn't like it; I renamed to .cpp and all the red disappeared ;) Thanks for your help!
Eclipse may or may not be pulling the paths to index from your build setup, depending on the configuration. Most likely, it is not...it's building correctly because your build setup is just fine, and you can probably build by hand.
The CDT indexer (which is the engine for deciding where all those pretty underlines, as well as code completion, F3 declaration jumping, etc comes from) isn't smart enough in a lot of cases to parse out your Makefiles and know where to look for headers and source. You need to tell Eclipse that information manually.
Go to Project Properties -> C/C++ General -> Paths and Symbols.
The amount of work you need to put into this can vary greatly, depending on your environment. If this external library is the only thing giving you headaches, then you probably just need to add the paths for that library and reindex:
Right-click on the project and select Index -> Rebuild
For starters, what color is the underline? This makes a difference, as yellow means it's a warning, and red means it's an error (critical, will not build in most circumstances).
Second, you need to look at the "Problems" tab to see if there are actual errors. If there is nothing there, then it did indeed compile correctly.
Now, back to the original question. Depending on the type of project you are building, this type of behavior is not that uncommon. Eclipse seems to do a poor job of indexing certain projects. When you run "make all" from the command line (which is effectively what Eclipse does during build) it is likely resolving all of your code and building it just fine.
However, Eclipse uses a different, separate tool for indexing all of your source code and resolving variable/function definitions and declarations. This is literally a case of the left hand not knowing what the right hand is doing.
The solution below worked for me:
Click to your project using right click. Then: Properties -> C/C++ General -> Paths and Symbols -> Symbols -> GNU C++.
Almost for sure there are no symbols at all if you have this problem. Add symbol "__cplusplus" with value "201402L"
After this:
Right click on Project -> Index -> Rebuild
You are done.
I had include folders in
Project Properties -> C/C++ General -> Paths and Symbols -> Includes
When I removed those, the red underlines went away, i.e. the build and the IDE where in sync.
When resolving symbols, CDT indexer seems to consider all header files irrespectively of which ones are actually included in the compilation unit. There is a corresponding bug report filed with Eclipse Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=439553
In my case the problem was due to adding "-std=c++17" flag in the language standard field in the project properties under the compile dialect. After that the build was passing with errors, but the program was running fine. So the trick of Index>Rebuild resolved everything.
If you changed something in the configurations, (example, editing in *.cproject file with notepad++) , the below options helps.
Build Configurations --> Clean All and then Index --> Rebuild
I had the same problem.
Index -> Rebuild didn't help.
When I added line #include <avr/iom1280.h> in main.cpp and made Index -> Rebuild underlines dissapeared.
Then I deleted line #include <avr/iom1280.h> and project still without inderlines.
Replace iom1280.h with name of your controller. Look at the "avr\include\avr\" folder for available names
Eclipse does not work as well with C++ as it does with Java, but it should warn you about issues once you press "Rebuild" in the menu bar.
Try that, and see if it resolves your problem.
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 a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
I'm using Eclipse with C++ code via linked resources on Linux. The code analysis index seems to be corrupted (Goto definition lands the cursor close to, but not on, the definition) Refreshing resources doesn't fix it, neither does restarting Eclipse.
Is there a way to flush the index and rebuild it?
Right-click on your project, go under the Index submenu, and choose either "Rebuild," "Update with modified files," or "Freshen all files."
I don't know the difference between those three options, but one of "Update with modified files" or "Freshen all files" usually fixes it for me.
Also, I'm sure you've already done this, but make sure that you're running the latest version of the Eclipse CDT. Current versions seem to have much more reliable indexing than previous versions.
From http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg10390.html, the differences between "Rebuild," "Update with modified files," or "Freshen all files":
Rebuild: Works for entire projects, only. Clears the index and indexes
the files from scratch. When cancelled it leaves you with an empty or
partial index.
Update with Modified Files: Works on a resource
selection. Checks on individual files whether the timestamp or the
scanner-config has been changed and updates the index for the changed
files.
Freshen All Files: Works on a resource selection. Updates the
selected files in the index. The index is not cleared, it is safe to
cancel the operation.
Go to your project properties -> C++ general -> Indexer.
Do this with 'project specific settings',
(or on 'Configure Workspace Settings...').
Deselect 'Enable Indexer' hit Apply.
Select 'Enable Indexer' hit Apply.
This should completely wipe out and rebuild the index.
Neither of the above worked for me (Eclipse Indigo), index still broken and refusing to rebuild properly. Until applied this one:
http://slsam2.blogspot.com/2012/02/eclipse-cdt-index-not-working.html
The crucial bit of the linked post is this:
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code.
I still wonder how Eclipse can uncontrollably shoot itself in the foot like that. I suspect that installing additional packages can trigger it. Perhaps JavaScript support in my case.
delete only the .pdom file under .metadata.plugins\org.eclipse.cdt.core helps, I got the indexer screwed after upgrading Neon.2 to Neon.3 and this seems to solve the problem.
(this comment already exists above but am not allowed to confirm it up there).
I found that I had the global indexer set to 'Use the build configuration specified in the project's indexer settings',
and the project's indexer set to NOT use project specific indexer settings.
Regardless, it was using the same fixed configuration for the indexer regardless of which configuration I had selected.
The fix:
Window-Preferences, C/C++, Indexer. Select "Use active build configuration" in section "Build configuration for the indexer".
Happy days.
Did you try adding -clean to the command line for the eclipse executable?
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code. worked for me
I started with trying Josh Kelleys and mmmmms answers without any luck, but I finally fixed it by checking my include paths.
One way to see them are in the Project Explorer, expand project and there should be an entry "Includes". Inside that, check for a small yellow warning triangle on each include path. If that triangle is present eclipse most likely doesn't recognize the path.
The include paths are edited through right-clicking on "Your project" in the Project explorer, then choose "Properties" --> C/C++ General --> Paths and Symbols --> Includes.
I see three language options, Assembly, Gnu C, Gnu C++. Choose the correct one before starting to add paths (likely Gnu C++). After adding all the paths, -->Apply --> Ok and rebuild index if you're asked to.
My erroneous workspace paths looked like MyProject/MyProject/folder when it was supposed to be MyProject/folder.
For me the "Problems"-view is always slow to update, even after rebuilding index. To be sure that the error is still there, double-click the problems entry so that eclipse opens/reloads the file in question. This often seems necessary for me to update the "Problems" view.
I don't really know if it was eclipse or my scm that messed it up. Anyway, hope it helps someone!
I use Luna and builds with an external makefile.