"Errors exist in the active configuration..." Eclipse Dialog when Debugging - eclipse

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.

Related

Could not find or load main class in both Tomcat and Workspace

I have been tasked with adding some new features in a project I worked on a while back. It's been given some new features since I last worked on it, and the development environment has changed. I'm having a lot of troubles bringing my environment up to date with all the dependencies and external folders.
After solving a host of problems, when running the Tomcat 7 Server in Eclipse I was coming across a message:
Error: Could not find or load main class Path\To\Workspace\.metadata\plugins\cont
I tried deleted the Tomcat Server and then recreating it with the same settings, as well as deleting my .metadata folder from the workspace. Now I can't even get Tomcat to configure right:
Error: Could not find or load main class Files\ApacheSoftwareFoundation\apache-tomcat-7.0.26.
Why isn't this working? It worked before I added a couple of needed subdirectories but I'm stumped now.
Just was searching for the same problem in Eclipse("Could not find or load main class").
It turned out in my case that there was an extra space in launch configuration arguments tab. (In Java EE perspective go to Servers, click on Tomcat server, in Overview window select 'Open launch configuration' and then go to Arguments tab). Arguments are listed as
-Dx.y.z=1 -Da.b.c=2 ...
and so on, but as the dialog itself is small and arguments go across multiple lines it's not always clear where there is a space and where there is a new line. In my case it was
-Dx.y.z =1 -Da.b.c=2 ...
(there is a space before =1) which confused Tomcat and I got "Could not find or load main class" error.
It's not necessarily your case but somebody else can come across this and find it to be the answer.
In the .metadata folder eclipse saves it's internal configuration, so you should not affect it manually. The errors give you the clue to get that resource it's looking is not accessible what ever it exists or not. Try to find it manually to check if it exists, then try to make it accessible, fix the path, change permissions, etc. May be you have classpath issue, who knows.
In Eclipse I added a Tomcat Server and it was working fine. I stopped the server to alter the settings. Specifically, I checked the 'Enable security' box. When I tried to start, I got this error. So I unchecked the box and tried to restart the server - same error. This thread led me to check the launch configuration VM arguments. Sure enough, Eclipse had not handled the checkbox (and unchecking it) correctly. The VM arguments had two places where it repeated strings without quotes. Check there to see if it has been malformed.

Eclipse #ifdef error using JNI, Android NDK and Vuforia

With Vuforia's ImageTargets sample application, I tried using OpenGL ES 1.1 by setting USE_OPENGL_ES_1_1 to true in jni/Android.mk and uncommenting and changing the corresponding line in AndroidManifest.xml (). After converting the project so that it has a C++ perspective and associating ndk-build and the proper include directories, I could successfully run the application on my Android device.
However, the problem is that once I open up jni/ImageTargets.cpp, I get several errors from Eclipse, all from places where OpenGL ES 2.0 code would execute, the first one being:
Description Resource Path Location Type Symbol 'vertexHandle' could
not be resolved ImageTargets.cpp /ImageTargets/jni line 402 Semantic
Error
Sure enough, vertexHandle is defined at the top of the ImageTargets.cpp, inside the "#ifdef USE_OPENGL_ES_2_0" block. Because USE_OPENGL_ES_2_0 is not defined (per Android.mk), the code should be able to compile successfully, and sure enough, ndk-build does not report any problems. So it seems that only Eclipse reports the problems and when I run the project, Eclipse says, "Your project contains error(s), please fix them before running your application." And thus, I cannot run my application anymore. In a sense, it's kind of strange that this never occurred until I opened ImageTargets.cpp and Eclipse "discovered" the errors.
The best work-around I've found so far is to just delete or comment out those lines (that should not be causing problems because USE_OPENGL_ES_2_0 is not supposed to be defined)... Is there a better way to deal with this problem? Did I miss a setting in Eclipse that should solve this?
I've found a solution: go to the project properties -> C/C++ Build -> Discovery Options -> Check "Automate discovery of paths and symbols"

Why do I get this error in Eclipse - can it be that Java runtime version is incompatible?

In Eclipse(version 3.6.2.M201102101200/Helios service release 2). I am getting a strange error when I run a large Java project called ACE toolkit. Below is a picture:
What are possible reasons it would do this?
can it be that Java runtime version is incompatible? The project was built for Java 1.5, but I have 1.6 running.
I appreciate any tips or advice.
There could be any number of reasons for eclipse crashing, from insufficient memory to a misbehaving plugin. The first place to start troubleshooting would be the C:\path\to\your\workspace\.metadata\.log file. You might find something helpful if you examine the end of this file soon after eclipse crashes.
From the documentation:
Eclipse has a log file where problems are recorded and usually this is the first thing that an Eclipse developer asks for when you report a problem. The log file can be found in a couple of places:
Workspace log - This is the most common location for the log file, It is stored in your workspace in the meta-data directory. Check out
workspace/.metadata/.log.
Configuration log - Sometimes information is recored in the configuration log file instead of the workspace log. (especially if
the workspace hasn't been created yet, there isn't one, or it cannot
be created) Check your configuration area for a configuration log
file. (configuration/.log)
Startup - Occasionally problems happen in the system really early before there is a workspace and before there is a configuration area.
This means that there is nowhere to write the log file so information
is written to the console, See the notes below on running with a
console to get these messages.

Perl EPIC on Eclipse: "\Perl\Directory is not a valid location for linked resources"

I am trying to debug a Perl script under EPIC on Eclipse (on Windows 7). When stepping along in the debugger, when it reaches the place where is has to jump to another package (called "Utilities.pm") due to a subroutine call, it gives the following succession of Eclipse errors:
'E:\Perl' is not a valid location for linked resources.
EPIC cannot access files located in folders on the path to the workspace folder, nor within the workspace folder itself.
An unexpected exception occurred while creating a link to E:/Perl/Utilities.pm
I am aware of this:
eclipse: Not a valid location for linked resources
and this:
Eclipse gives error "... is not a valid location for linked resources."
But I can't deduce from them how to solve my case.
Running as Administrator doesn't help.
TIA
Helen
Eclipse version 3.7.1 build M20110909-1335, EPIC version 0.6.44, Active Perl 5.14.2 running on Windows 7.
Note: cross-posted on: http://perlmonks.org/?node_id=972408
Apparently there was some inconsistency in the Workspace - Project -Linked Resources file structure. I have deleted the entire project, restarted from scratch, and then this error did not show up again.
But, the program hanged at another Eclispe/EPIC error, which I will post separately soon.
Here is the following problem:
Perl debuuger: on a run-time error, the debugger terminates with a cryptic message instead of "catching" the error

Carbide does not include debugging info for some files

In Carbide 2.0.2, if I set active configuration to be "Phone Debug GCCE", build the project, go to Debug perspective, choose "Executables" tab, and select the executable file, Source File Name/Location window will list all the files I am able to use while debugging.
The problem is that the list does not contain all files from the project, even though their code is successfully linked and executed on a device. As a consequence of the issue, I am not able to set break points in these files.
What is the catch and how can I fix it?
Thank you.
This is a problem with the version of GCCE that is used by default with Symbian. It has a number of bugs with debug information, including sometimes missing line information for some files.
The alternatives are (a) the commercial RVCT compiler, or (b) follow the in-progress work to move to a newer GCCE compiler. A good start for that is here:
http://developer.symbian.org/wiki/index.php/The_GCCE_toolchain_initiative