I try to find something that could help me but nothing was good so far.
I would like to know if there is any option to comment some lines of code while i start building/debugging?
I don't want to do it manually ("edit and continue" manually isn't a solution). I want "tell VS" to automatically comment specified line of code if i start to build or debug.
I need this line of code when i am testing app at server, but when i do it locally i have to have it commented.
Hope you understand my problem and will give me fast solution, thank you.
I use VS2013 and C#.
Would preprocessor directives help you? By default the DEBUG directive is enabled for Debug configurations, so any code between #if(DEBUG) and #endif will only be executed in your Debug configuration.
One possibility:
if( !System.Diagnostics.Debugger.IsAttached )
{
//code which should only run if not being debugged
}
Otherwise use preprocessor directives as Jenszcz suggests.
Related
I'm trying to build a project with vitis using the library xuartps.h but I can't because of this error
code screenchot
I don't know why this happens. Could you help me please?
This is an include file. It gets literally copy-pasted on your sources. On top of that, the compiler could notify the error around the wrong line, but it could be before or after the one which is actually wrong.
Check your sources that include such header, you must miss a semicolon there, or another typo. You should not look into the header.
Why are the breakpoints set in Script Tasks of SSIS package (VS2005) being ignored??
I created a new package, added one simple Script Task to it, and no matter where I set the breakpoints in that task, they are being ignored. Help please!!!
Seems to be a known bug and there are several workarounds, depending on how you are running the package and what's going on in the background. This thread has a lot of good information about it:
http://social.msdn.microsoft.com/forums/en-US/sqlintegrationservices/thread/710c4865-bc74-4f1d-a3b9-865109ee25c7/
Hope it has something that will work for you!
Did you add the breakpoint while you were still in Debug mode? I've done that often. If you add the breakpoint while in debug mode, click 'Stop Debugging', and then run the package in Debug mode again, the breakpoint will be ignored.
Make sure you are not still in debug mode when you add the breakpoint.
Yes they are being ignored, the only way I know of to get any debug information is using the MessageBox.Show() method.
This happens to me pretty often. For example, right now I have the debugger stopped at a breakpoint in a method . . . and it isn't displaying any variable values at all. Other times, it displays some, but not others.
Can anyone explain?
The most common reason for this is that you're trying to debug code compiled with optimisation enabled and/or no debug symbols. Typically this will be because you're trying to debug a Release build rather than a Debug build but it can also happen with Debug builds if you've made inappropriate changes to the Debug build settings.
Another less common possibility is that you've hosed the stack.
I had this issue (using Swift), I spent ages crawling through my git commits to find where to problem started.
For me, I was using Facebook Tweaks library, but I was (unnecessarily) importing it from my project-bridging-header.h file.
Once I got rid of it, I got my debugging back.
for example, in my bridging header I had:
#ifndef PROJECT_Bridging_Header_h
#define PROJECT_Bridging_Header_h
// Facebook Tweaks
#import "FBTweak.h"
#import "FBTweakStore.h"
#import "FBTweakCategory.h"
#import "FBTweakCollection.h"
#import "FBTweakViewController.h"
#import "FBTweakShakeWindow.h"
#endif
I removed all the imports and just imported it as usual in my AppDelegate import Tweaks.
e.g:
#ifndef PROJECT_Bridging_Header_h
#define PROJECT_Bridging_Header_h
// Removed Facebook Tweaks
#endif
and in my AppDelegate.swift
import Tweaks
This fixed all my debugging issues, everything works as expected and I can also using Facebook Tweaks.
Note: I don't think this is an issue with Facebook Tweaks itself, you may have some other library causing the same issue. The idea is to remove things from your bridging-header one by one and see if you can narrow down the issue.
I think I read somewhere that if a library is causing many issues behind the scenes, this can stop your debugger working.
If this doesn't help, try crawling through your git commits and see at what stage the debugging stopped.
other similar issues on SO:
Xcode Debugging not showing values
Xcode debugger doesn't display variable information after installing CocoaPods Podfile
If you're having similar issues hope this helps! 👍
A possible solution is to set the Optimization Level for your current target Debug scheme to none.
Project -> Target -> Build settings -> Optimization level -> Debug (or whatever fits your project) -> None
Source:
https://stackoverflow.com/a/14948486/3590753
I've had similar issues using LLDB. Switching it back to GDB seems to address it. Obviously this isn't solving the problem, but its a workaround anyway
My issue was that I had address sanitizer enabled. Disabling sanitizer resolved my issue in XCode 8.2.1
You can get the value of any variable in the console by writing:
po name_of_an_objectCVar
or
print name_of_a_cVar
If your breakpoint has "automatically continue after evaluating options" set, then it won't write to the variable view - FYI
I know this is old, but i ran into same problem too. I could not see any summaries of any objects, just types and some address code. After 4 hours of struggling with compilers, debuggers and other solutions i was about to give up when by accident i found this option in debugger. "Show Summaries". Just by clicking it everything got fixed and now i see all variable summaries!
Had the same issue using Xcode 6.4 running the app on device. Running on simulator will show all variables on debugging variables panel.
There is a situation I have seen where Xcode can't cope with return value optimisation (RVO) -- if the compiler decides to apply RVO to a variable then it may not appear in the variables list. You can disable this in g++ and clang with the compiler flag -fno-elide-constructors
See also Understanding eliding rules with regard to c++11
For Swift mix OC Project which use pod
Fixing it by removing useless header(that import with framework by pod) xx-Bridging-Header.h
eg.
In the past I import header with #import "GCDAsyncSocket.h" which I was added in podfile
platform:ios, '8.0'
use_frameworks!
target "roocontrollerphone" do
pod 'CocoaAsyncSocket'
end
just remove it in that xx-Bridging-Header.h file
If you are using the #property feature of Objective-C 2.0 the debugger does not display those variables unless they are backed by explicit ivars in your Class interface. This is slated to be fixed in Xcode 4 as I understand it.
temporary solution when it happpen to me :
right click on the property
jump to definition (u can do it manually and scroll to the #synthesize in the top of the file)
now, if the line is like this :
#synthesize myObject = _myObject ;
set the mouse cursor on the "_myObjects". that what worked for me..when i have problems.
I figured out why it is not working in XCode 4.6 - all of the variables in my object, self, were declared in the .m file instead of the .h. When I moved one of them back to the .h file, it showed up in the debugger. Sounds like a bug with XCode in that it cannot "see" variables declared in the implementation file.
For me it works changing the content of display variables panel to Local Variables and then back to Auto.
This solution worked on XCode 6.3.2, Swift type project.
You need to disable two types of build optimizations in the build settings. By default, the "swift compiler - code generation" optimization level for debug build is set to fast. You need to set this to none. Also check that the "apple llvm 7.1 - code generation" optimization is set to none for debug build.
Finally, check that you are building the debug build in the "architectures" section of your build settings.
Hope this helps.
I have been stuck a while with this problem and finally find out a solution.
I think that many reason can causes this bug but in my case here is the solution.
While you are in the breakpoint position check the included classes.
I was including using double quote a file which was located using include path.
#include "MyClass.h"
instead of
#include <MyPorject/MyClasses/MyClass.h>
So if you have this problem try to double check your inclusion and import.
I know it seems weird but worked for me and I have been able to reproduce it by putting back the Double-Quote include.
One possible reason for the debugger displaying seemingly wrong values is that the variable type is of Any?.
E.g.
var a: Any? = 12
var b: Int? = a as? Int // b=13483920750
var c: Int = a as? Int ?? 0 // c=1
In the example above, b holds the correct value of 1 even though it is not displayed as such.
I've had the same issue and I fixed it by reinstalling all Pods. Just delete them and install again.
I'm developing a library for use in other apps and this library has lots of debugging and logging statements thanks to NLog.
Is it possible to exclude the reference to NLog.dll when I switch to release mode?
Cheers,
You can manually edit the csproj file, and do something like this:
<Reference Include="NLog" Condition="'$(Configuration)' == 'Debug'" />
This only makes it reference that assembly in Debug. I wouldn't recommend doing this often though, because this behavior isn't reflected in the references list in Visual Studio when you change the configuration. It does work when compiling though
The only way I know is to take the reference out completely and call the assembly via reflection. Then, you should only log if the assembly loads.
I can't think of a good way to do this. Unless maybe you wrote a stub reference for NLog.dll. Since you are using the reference in your code I don't see how you could just remove it in your release.
Probably too late now but in the future you could write a class to wrap NLog.dll and then just change it in one place so it wouldn't actually log in the release version. Or have some sort of flag.
There is no reason for removing a reference in case you are sure that no code will be in use from that DLL. In that case you can simply remove DLL.
Why would you want to do that?
If you want to stop logging, you can programatically turn off the logging. The performance hit will be minimal. (I have had great success with NLog even when logging cross process.)
Otherwise, you need to wrap it as described above.
-Scott
My problem is that I set some breakpoints in my code and some of them aren't working. In some places it complains about "Unresolved Breakpoint".
Does anyone have any clue why this is happening? I am using gdb, by the way.
EDIT: Yes, of course is compiled with debug information. It only happens at some classes or points in the code. And I am pretty sure that that part of the code is reached because I can reach it stepping
EDIT: The solution from Richard doesn't work; thanks anyway. I am compiling in Debug, without any optimization.
Could it be that you are trying to set breakpoints in a shared library that has not been loaded yet. That won't work until the library has loaded. Newer gdb allow to set deferred breakpoints, but that may not (yet) be supported by CDT. A workaround is to set a breakpoint in a place that is available from the beginning that will be reached when the shared library in question is already loaded. Then set the other breakpoint in the shared library. Now it should work. It's a bit more tedious, but usually works.
From the GDB documentation:
For a pending breakpoint whose address is not yet known, this field will contain 'PENDING'. Such breakpoint won't fire until a shared library that has the symbol or line referred by breakpoint is loaded.
I have found that sometimes switching the referred Process Launcher from "GDB (DSF) Create Process Launcher" to "Standard Create Process Launcher" has fixed this problem for me. Other times, just deleting all breakpoints and restarting Eclipse does the trick.
"Unresolved Breakpoint" just means that GDB did not find code location corresponding to the file and line on which you attempted to set a breakpoint.
Are you trying to stop in a constructor?
If so, you are likely seeing this cently fixed GCC bug.
Sometimes optimizations will cause breakpoints to be skipped as well. Make sure you're compiling with -O0
I have found that using F8 (resume) doesn't stop at my breakpoints. But, if I have Stop On Startup : main set then then step over my code (F5/F6) then my breakpoints are hit. I don't have any special compiler options other than -g or -g3. Hope that help...
Make sure the breakpoint type is correct. For C/C++ it's a tiny blue dot. If it looks like anything else, chances are the breakpoint type is incorrect. I would try to close the file, right click on it -> open with -> C/C++ Editor. This worked for me.
If other answers here didn't solve your problem, it is possible you are having the same problem I had (which was the result of having an outdated version of GDB). This is likely the case for anyone using GDB on Mac.
See my question and answer here:
GDB does not break on some lines of code when using multiple source files
Do you place a breakpoint in a template class/function? I've met the same problem: I can step through the code of templates but breakpoints do not work.
I guess eclipse does not understand that it has to place breakpoints in all instantiations of that class:
template <typename T>
int doit(T a) {
return a.do(); // <-- breakpoint here
}
...
A a;
cout << doit(a);
I think it will wait for doit(...) and never for doit(...).
At lease gdb itself stops on the breakpoint if I set it to the function: 'doit'.
I had a similar issue with GDB. It seems that it was caused by identical source code filesnames even if they have different paths. I renamed the duplicates and GDB worked just fine after that.
Silviu
i had the same problem,
1.- Removed the breakpoints.
2.- Restart eclipse
3.- Clean the project by using project -> clean
4.- Add again the breakpoints and start your debugging.
This solved my issue.
IF you are using GDB as a debugger, make sure you are using both flags:
-g and -ggdb
You can either edit the make file directly,
FCFLAGS = -g -ggdb (some other flags you might have)
or go to Debug Configuration (It's in the menu that drops down when you click on the little arrow besides the bug icon.) Select the project you are debugging, and click on the debugger tab. Check you are using gdb, and add the flags here.
Amazing that there are so many different answers to this question. There is still (2020) a problem in Eclipse 2019.12, CDT 9.10, RHEL 8.0, x86_64. In my case, I can fix it by adjusting the breakpoint properties, and changing it from 'regular' to 'hardware' (select the breakpoint window, then right-click on the breakpoint, Breakpoint properties, common, type).