When press the Run button in GoLand, it will recompile the code even without any change for the code, why?
This is done by the Go compiler and it should be very fast if nothing changed, thanks to the compiler cache introduced in Go 1.10.
And the reason the recompilation step is required is simple: there is no simple way to tell if indeed nothing has changed or not in the build as external resources outside of the compilers reach could affect the results.
So, the IDE invokes the compiler first, then it starts the debugging process.
A better question would be: what are you trying to do and why is the recompilation a problem in this case?
Related
I am getting some mysterious compiler type related errors in my ts code. I have another thread addressing them.
But I know there will be no adverse reactions to my code, so I would like to force it to compile and make my js files anyway so I can do some run-time debugging.
I have seen a comment or two about the project compiling despite some build errors. How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
I have VS2013 and TS 1.5.
Thanks, Brad
How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
Make sure that in your csproj you have noEmitOnError set to false.
I find that Swift is quick to mark down changes i make as compiler errors in the side panel, and then when i compile, it decides i am right after all. Is Swift just pessimistic about my code?
Can I get the compiler to wait for me to finish the line before declaring it wrong?
There is nothing pessimistic. Xcode uses the same tool - the compiler - to get the errors. However, it usually compiles only one file, using cached compiled objects for the other files. It also doesn't invoke the compiler after every change in your code, so errors that are already fixed can stay there in the side panel.
Building the project fully forces Xcode to refresh the cache and get the current list of errors from the compiler. I do agree that Xcode has many imperfections and this is one of them. When you can't find an error, just rebuild the project.
Note that IDEs for other languages often rebuild the project automatically to solve such problems. This is currently not an option in Swift because it would take too much time.
Im working on Arduino Uno board recently im stuck with my code, i couldnt debug using print() in ArduinoIde.So i downloaded AtmelStudio 6.2 for debug purpose.
when i set the breakpoint and try to build .Im getting the warning
The breakpoint will not currently be hit. Unable to set requested breakpoint on target.The current selected deviceis unable to set breakpoints during runtime
please help me sort this issue
Following workarounds worked with the same problem using ATMega 168P on Atmel Studio 7 with Atmel-ICE.
1. Assembler
Insert the following assembler code where you want your breakpoint:
asm("break");
Please note, this is a really ugly solution and not suitable for all situations. It only works with DEBUGwire and makes your program stop in any case, even if no programmer is attached.
2. Create new project
Creating a new project at a different location helped as well. I copied all the required files to the new folder. The new location has a short path (C:\atmel\project...) and contains no spaces, no umlauts etc.
I had a similar problem, the difference was that I could only hit breakpoints in the original modules of my project (i.e. those already existent when I created the .cproj), any modules I added later wouldn't have the program stopped in breakpoints placed on them.
The solution (2) mentioned by #pafodie worked to solve this, but in the process I found a simpler way: just delete the .atsuo file. It will later be automatically recreated, and the problem disappears (at least until you add more modules). It seems AS6 caches something there that isn't updated when new files are added, or does it incorrectly.
I might've found a solution that works, for me at least! You need to disable compiler optimization. In Atmel Studio,
Hit Alt+F7 > ToolChain > Optimization {there are 2 Optimization
windows but only one fits the shoes} > Optimization level > None
I found it here, explained better than I did: https://www.microchip.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-8FF26BD2-DBFF-48DD-91FB-8585D91A938D figure 5
If using external Makefile, make sure the -g (debug) flag is set in CFLAGS.
Otherwise, Atmel Studio would have no idea how the source files correspond to the compiled binary.
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).
I have a workspace for running an H.263 Video Encoder in a loop for 31 times i.e. the main is executed 31 times to generate 31 different encoded bit streams. This MS Visual Studio 2005 Workspace has all C source files. When i create a "DEBUG" configuration for the workspace and build and execute it, it runs fine, i.e. it generates all the 31 output files as expected.
But when I set the configuration of the workspace to "RELEASE" mdoe, and repeat the process, the encoder crashes at some test case run.
Now to debug this is verified following:
Analyzed the code to see if there was any variable initialization being missed out in every run of the encoder
Checked the various Workspace(Solution) options in both the modes (DEBUG and RELEASE).
There are some obvious differences, but i turned the optimization related options explicitly same in both modes.
But still could not nail the problem and find a fix for that. Any pointers?
-Ajit.
It's hard to say what the problem might be without carefully inspecting the code. However...
One of the differences between debug and release builds is how the function call stack frame is set up. There are certain classes of bad things you can do (like calling a function with the wrong number of arguments) that are not fatal in a debug build but crash horribly in a release build. Perhaps you could try changing the stack frame related options (I forget what they're called, sorry) in the release build to the same as the debug build and see whether that helps.
Another thing might be to enable all the warnings you possibly can, and fix them all.
Could be a concurrency problem of two threads. The DEBUG configuration slows the execution down, so the problem does not occur. But, only a guess.
Interesting problem.. Are you sure you have no conditional compilation code lurking around that is not being compiled in release mode? i.e:
#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif
Thats the only thing I can really think of.. Never experienced anything like this myself..
Can you add the debug symbols to the release build and run it in the debugger to see where and why it crashed?
Yeah, those bastard crashes are the hardest to fix. Fortunatly, there are some steps you can do that will give you clues before you resort to manually looking at the code and hope to find the needle.
When does it crash? At every test? At a specific test? What does that test does that the others don't?
What's the error? If it's an access violation, is there a pattern to where it happens? If the addresses are low, it might mean there is an uninitialised pointer somewhere.
Is the program crashing with Debug configuration but without the debugger attached? If so, it's most likely a thread synchronisation problem as John Smithers pointed out.
Have you tried running the code through an analyser such as Purify? It's slow but it's usually worth the wait.
Try to debug the release configuration anyway. It will only dump assemblies but it can still give you an indication of what happens such as if the code pointer jumps in the middle of garbage or hits a breakpoint in an external library.
Are you on an Intel architecture? If not, watch for memory alignement errors, they hard crash without warning on some architectures and those codec algorithm tend to create those situations a lot since they are overly optimized.
Are you sure there are no precompile directives that, say, ignores some really important code in Release mode but allows them in Debug?
Also, have you implemented any logging that might point out to the precise assembly that's throwing the error?
I would look at the crash in more detail - if it's crashing in a test case, then it sounds pretty easily reproducible, which is usually most of the challenge.
Another thing to consider: in debug mode, the variables are initialized with 0xCCCCCCCC instead of zero. That might have some nasty side effects.