There is a class in the Eclipse source code called JavaBuilder[1], which has DEBUG and SHOW_STATS flags (static boolean) that I'd like to enable to debug build issues, since they enable printing reasons for rebuild, eg:
if (DEBUG)
System.out.println("JavaBuilder: Performing full build since last saved state was not found");
I am guessing that they can be enabled with some argument in "eclipse.ini"?
I'd like to know what the argument syntax is, and where Eclipse's stdout is logged to.
Or if one can enable them without restarting Eclipse, of course.
[1] org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/builder/JavaBuilder.java
Looks like this is set by the org.eclipse.jdt.core/debug/builder trace option. The org.eclipse.jdt.core/debug option must also be set.
You can set this option by enabling tracing in the Preferences in the 'General > Tracing' page or by using a .options file (see this question)
The org.eclipse.jdt.internal.core.JavaModelManager class defines the trace options for the JDT code.
Related
In the Eclipse settings under General->Error Reporting there is the option "Enable debug mode". But what does it do? When I search for "Eclipse debug mode" I obviously only get results on how to debug programs with Eclipse, not about this option. I guess it creates more detailed log files?
(Or maybe more general: Is there a detailed explanation of every Eclipse option (at least for core and the normal packs from the official download page) somewhere?)
Speaking as one of the committers from the Eclipse Automated Error Reporting Initiative (AERI), this option is there to help us, the developers of AERI, debug the error reporting itself.
Switching the General > Error Reporting > Enable debug mode option on causes every error that shows up in the Error Log to cause an “An Error Has Occurred” notification – even if the same error has already been reported from this Eclipse instance. Also, AERI explains how it reaches its decision whether to send the report via additional messages in the Error Log.
Unless you are contributing code to AERI or need the extra verbosity to send us a detailed bug report, you should leave that option switched off (the default).
Related to the tooltip "Disables recently seen filters and increases the logging output" i assume that this is for sending exceptions and other error to the eclipse-developer team directly.
In the same page you can adapt the error reporting configuration.
When you install eclipse you get ask whether you want to support eclipse in sending errors to them. If you do not agree, this preference page helps to get it to work later on.
An "Errors exist in the active configuration of project X. Proceed with launch?" dialog appears while debugging code in Eclipse. Hitting the "Proceed" button results in successful debugging. There are no apparent errors with the launch configuration. A similar Run Configuration does not generate the error.
This is caused by an invalid path somewhere in your Eclipse project settings. There are a couple common sources for this kind of error.
You're working on a shared (version controlled, copied, etc) project where someone has hardcoded a path that doesn't exist on your machine, or uses an environment variable that you've not set.
Sometimes, you can find the offending path by looking at the full list of Error messages. If not, look in your project file.
The Discovery Options in your project properties has 'Automate discovery of paths and symbols' enabled - but the process is generating an error.
If you're using a version of Eclipse that warns you this option is deprecated, uncheck the option to disable it and fix any includes in 'Preprocessor Include Paths' instead. If not. . .try it anyway.
Depending on your path changes, restart Eclipse and try again.
It starts the executable that was built last before you broke the build. That executable will be older then your source files. The reason you were able to debug is because your line numbers did not change for the code you've debugged - e.g. you may try break in main then introduce a compilation error and move main a couple lines below - the debug will highlight the wrong lines when it stops.
Back in the day I was debugging node.js applications using the ChromeDevTools. Breakpoints would be synced or reset on remote, so that no matter what, the breakpoints in the Eclipse breakpoint window would always match the actual breakpoints.
Also, setting up the Source Mapping as described here would cause Eclipse to break inside my actual local files, not in a read-only V8 window.
These days, ChromeDevTools is outdated and unmaintained. I started using Nodeclipse and their V8 debugger.
But now, when debugging, Eclipse keeps breaking on breakpoints I had already unset or removed. Seemingly irregardless of my setting here:
Also, whether or not it's a break point I meant to break on, A new read-only editor opens with the V8 (Chromium) icon in stead of the javascript-icon. If the original name was e.g. index.js, the script that opens is index.js (20).chromium.
What is changed? How exactly does one set up the Nodeclipse V8 debugger for proper breakpoint syncing and source mapping?
There is nice intro info given, but still a discussion should follow, that does not fit to StackOverflow format. Please create and follow with an issue on https://github.com/Nodeclipse/nodeclipse-1/issues
These days, (since Nodecipse 0.2) Launch configuration is created automatically, so most users may even don't know about it existence. And it is needed to be recalled looking at code how actually launch configurations are created and synced. Related source are here:
https://github.com/Nodeclipse/nodeclipse-1/tree/master/org.nodeclipse.debug/src/org/nodeclipse/debug/launch
I'm trying to debug a program written using Go inside eclipse. I can set and hit breakpoints pretty consistently, but I cannot view the contents of my variables. When I start debugging the program, I always get the following error on my console.
warning: File "/usr/local/go/src/pkg/runtime/runtime-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
line to your configuration file "/home/johnlawrie/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/johnlawrie/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
Thinking that the problem might be due to the error message, I put the entry into my .gdbinit file as instructed. However, I get the same message every time I run as if I did nothing at all. This is the contents of my /home/johnlawrie/.gdbinit file
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
Any ideas what I need to do to make this change take effect? I have tried logged off and back in.
Thanks,
John Lawrie
It did learn what was happening. When gdb is started from Eclipse/CDT, it is started with option -nx, which means it doesn't load .gdbinit in the home directory.
I was able to get this to work by creating a .gdbinit file as a peer to the src, bin, and pkg directories in my workspace and adding the following line to it
set auto-load safe-path /usr/local/go/
It should be add-auto-load-safe-path /usr/local/go/src/pkg/, not the path to the script.
Also keep in mind that gdb doesn't really work with Go, specially v1.3.
From http://golang.org/doc/gdb:
GDB does not understand Go programs well. The stack management,
threading, and runtime contain aspects that differ enough from the
execution model GDB expects that they can confuse the debugger, even
when the program is compiled with gccgo. As a consequence, although
GDB can be useful in some situations, it is not a reliable debugger
for Go programs, particularly heavily concurrent ones. Moreover, it is
not a priority for the Go project to address these issues, which are
difficult. In short, the instructions below should be taken only as a
guide to how to use GDB when it works, not as a guarantee of success.
I have several launch configurations for the code I work on.
One configuration (#1) means "run the unit tests for the file in the frontmost editor (i.e. selected resource)". I would really like to be able to always make this be bound to a key.
Another configuration (#2) means "run the server that I am working on (in the frontmost project) so I can test it interactively".
Yet another (#3) means "run some automated acceptance tests against the server".
I always want to have #1 close at hand, easy to run from a single keystroke. Plus, I want to be able to run #2, watch it start up in a console, and when it's ready (since it's not entirely trivial to automate this) hit the key for #3.
This is possibly similar to the question for binding a key to a specific build configuration, but the answers there look very specific to builds, and as I'm using PyDev, I don't have a "build" step at all.
Also, given that I'm using PyDev, an answer in the form of a pyedit_* script would be appreciated just as much as a "native" answer for eclipse.
Maybe Eclipse Runner plugin could make it easier for someone to handle launch configurations. It doesn't allow to assign key binding to launch configurations currently but I opened a feature request Key bindings for launch configurations
Not to a specific launch Configuration , but you can bind a key to run Last run Configuration ,
Windows->preferences->General->Keys->Run last launched external Tool
You can do the following (for #2 and #3), after having those run configurations created:
Go to Run > Run Configuration > Select the run configuration you want > Common > Display in Favorites Menu > Check Run/Debug. This will make it always appear as the first on the menu.
This will make it appear in the menu in Run > History and Run > Debug History, then, you can access it through Alt+R, T, 1 (and 2 and 3) to run your configurations or Alt+R, H, 1 (and 2 and 3) to debug.
And for #1, as Piotr Dobrogost said, you can just use Ctrl+F9 in the current editor and choose which test-cases you want to run (if you select a unit-test -- usually with Ctrl+Shift+Up or Ctrl+Shift+Down -- it'll be pre-selected for you) -- then, if you configured to always relaunch the last launch, as explained in http://www.pydev.org/manual_101_run.html, you can use Ctrl+F11 to relaunch the last launch.