Related
This isn't coding related, I hope that's fine. I've been trying to run a modpack through techniclauncher, but I can't get the launcher to even open.
If I have java 64bit installed, anything I open that uses java just stays in the taskbar/task manager for about 3 seconds, then closes with no error message. 32 bit java works, but I need 64bit so I can dedicate more than 1GB of ram to a modpack.
I am on Windows 10 x64 build 1903, my java version is JRE 8u231 but no matter which version of java I install the problem persists.
Things I've tried:
uninstalling/reinstalling
Using revouninstaller from Britec's tutorial
Installing an old version of java (Java 6 had the same problem, same with older versions of java 8)
jarfix
updating graphics drivers (gtx 1070 currently on 441.41)
I have no idea what caused it; it worked fine a few months ago and when I tried to launch a modpack yesterday the launcher wouldn't start. Even the java control panel doesn't work. Any help would be appreciated, thanks in advance!
[EDIT: screenshots of event viewer]
https://gyazo.com/70c9b5599fe3331e927171a6ac279e25
https://gyazo.com/1786c8011182933e3671481966394507
https://gyazo.com/da029d89cfdf0da6a3af4cb5a4c9b083
https://gyazo.com/a0a377129d51ee7b51a4b2aefce8723f
https://gyazo.com/4ad84929c5f1c0e93834289616f4afb2
This all happened at about the same time when I tried to open the Java control panel
The error message seems to indicate the crash has something to do with graphics / Direct3D. Finding the root cause might be difficult, but one thing to try would be updating your graphics drivers.
Another thing to try would be to disable Java's graphics hardware acceleration. The System Properties for Java 2D Technology page has instructions on how to do this. Under Windows, to configure globally for all launched Java applications, set the environment variable _JAVA_OPTIONS to -Dsun.java2d.d3d=false to disable Direct3D acceleration.
I'm using the eclipse neon IDE and I put it on the path: /opt/eclipse/eclipse and i am using Ubuntu 16.04 and Java 8. The problem is that when I write in the eclipse editor, this is going too slow. For example, I just typed and in the editor it still does not end.
How can I solve it?
Thx!
Try Netbeans, or IntelliJ IDEA.
A quick browse over the Interwebs shows that quite a lot of people are complaining about Eclipse slowness. Some have every manner of trick and configuration change to help speed it up. OK, you can put yourself thru all that hassle if you want, or, you can just switch to something that already works fine out of the box.
I had Eclipse Oxygen for PHP running on a CentOS 7 VM with 2G allocated RAM. I admit, that's pretty low memory, but that's the way it has to be right now. Eclipse ran so slowly, I finally gave up and killed the process from the command line.
I installed the latest Netbeans 8.2, and it not only installed more cleanly (no Java error messages, and it put an icon on the desktop), it ran PERFECTLY without changing a thing!
I eventually changed a couple of parameters, but the point is, I didn't need to change a thing to get decent performance. Even on a low-ram system, it ran plenty fast enough.
Don't blame the hardware. Not everybody has the money to buy the latest and greatest and fastest machines available, and software developers should not expect it. With some exceptions, if your application can not run adequately on 2G of ram, you are doing something wrong.
The Eclipse developers are doing something terribly wrong.
I had faced a similar issue with eclipse oxygen.
After a some research over different forums I found the following solution.
Step 1 : Open eclipse.ini file. If you find difficulty in locating the file, see this question Where's the location of the eclipse.ini file?
Step 2 : In eclipse.ini search for below 2 variables
-Xms
-Xmx
Xms indicates minimum ram that should be allocated to eclipse.
Xmx indicates maximum ram that should be allocated to eclipse.
Step 3 :Increment both the values. You can set the value as per your choice. Below is my preference.
-Xms512m
-Xmx2048m
Here
m indicates megabytes, if you don't specify m it will consider bytes by default.
The easiest thing to do would be to re-install eclipse, and if that does not work you could try to download an older version of eclipse. It could also be slow because your computer is slow.
I'm on a team of 6 developers and we are all using Eclipse Indigo on Ubuntu 11.04. At least once a day, if Eclipse is running, each of us experiences a total system lock-up. The only cure is a hard reboot of the PC. Some of us have had it more than ten times in one day. This does not happen if Eclipse is not running, so I can confidently say that Eclipse is the problem.
I have tried increasing the memory available to Eclipse by going into the ecplise.ini and increasing the Permsize, MaxPermSize, Xms, and Xmx. This has made no difference and everyone's PC is still locking up.
Has anyone experienced this before? I could understand maybe on one PC, but it happens on every single PC!
Java version: java-6-sun-1.6.026 JDK version
Ecplise version: Indigo SR1 BuildID 20110916-0149
Ubuntu version: 11.04 64-bit
EDIT: Ctrl-Alt-FnX keys do not work once the PC has locked up.
EDIT: I've revisited the eclipse.ini settings and increase the memory some more. So far I haven't had a crash yet. I will use the other developers as guinea pigs, but I'm hopeful that these settings will stop the crashing.
-XX:PermSize=256m
-XX:MaxPermSize=512m
-Xms1024m
-Xmx2048m
This is not to resolve Eclipse problem... which might be happening because of some display issues I suspect.
Instead of hard reboot you can press keystrokes Ctrl+Alt+F1 together to reach console and there you can login to a text based terminal and kill the Eclipse process.
more a comment than an answer, but I cant add you a comment yet.
I'm kinda using the same setup: Ubuntu 11.04 64bit with Eclipse Indigo SR1 RC3 64-bit (buildid 20110909, didnt had time or need to update to a newer release yet, but RC3 is stable for me). Make sure, you have installed the 64-bit version of Eclipse.
OpenJDK in combination with Eclipse didnt went well for me, so I changed to java-sun jdk 1.6/7. Make sure Eclipse is not referencing to the OpenJDK installation instead of java-sun jdk.
I had some issues with Eclipse Indigo (pre SR1) freezing in combination with SVN Subversive/m2eclipse plugins. For me it got better with the SR1 (RC3), but still not perfect (a freeze now and then). A while later Subversive SVN had an update, and now it's stable again. In short: make sure, you have installed the newest plugin versions (use eclipse update sites, no local copies). Older versions might lead to the same problems I experienced.
What other plugins are you using, can you verify if your Eclipse crashes without any plugins installed?
Two other issues I'm aware of: with Ubuntu Karmic Koala (9.10) rendering UI elements was broken/lead to crashes as well (GTK_NATIVE_WINDOWS). Later Eclipse had problems with the native scrollbars (think it was with Ubuntu 10.10 or 11.04). I'm pretty sure, problem 1 aint an issue anymore with Eclipse Indigo + 11.04. Problem 2 I'm not sure if it was 10.10 or 11.04. But I still start my eclipse with the following script.sh and it works for me, you could give it a shot as well:
#!/bin/bash
export LIBOVERLAY_SCROLLBAR=0
export GDK_NATIVE_WINDOWS=false
exec $(dirname $0)/eclipse "$#"
Try upgrading the kernel to the latest version. I think this lock up is caused by the kernel bug detailed on this page https://bugs.launchpad.net/ubuntu/+source/linux/+bug/924905
While you wait for better answers, I would definitely try a virtual machine like Virtual Box to:
Try to see if I can replicate the problem in a Virtual environment, which is similar to your actual environment. This way you can see if the problem the combination of the versions of software that you're using or your physical hardware.
Run Eclipse through the VM. It may not crash and will prevent you from having to do a full re-boot of the system, until you determine what the actual problem is.
I have a similar problem. From time to time it happens that the complete X11 desktop freezes. I can still move the mouse but clicks on elements have no effect.
In this situation I switch to the text console and kill eclipse. After I did that, everything works again.
I am using a laptop with an Intel graphics chipset. So I tend to blame it on the the graphics driver.
I have other computers with different graphics hardware where I haven't noticed the problem, but I don't use eclipse that often on them. On all I am using Ubuntu 11.10 64bit with gnome or unity desktop.
I have the same issues. It is very inconvenient. I have just confirmed that killing eclipse fixes the issue for me.
However, I have found something strange in that I can still click on the stupid overlay scrollbars. It's like they have the focus of the entire system.
What seems to have fixed the issue to me was to install the gnome shell and start using gnome 3, then turn off the overlay scrollbars in the startup scripts for X. I installed gnome 3 for a separate reason and disabled the scrollbars because I find them annoying, but I do find that this has solved the problem for me. You may be able to get away with just disabling the scrollbars, information for which is readily available on google.
I seem to have a 32bit vs. 64bit problem here. It should be simple to solve, but I'm hoping you can help me by pointing out the problem. I really want to avoid re-installing OSs, Eclipse, several plugins, JDKs and JREs over and over again to find a working solution. Many thanks in advance!
I build on a 64bit Thinkpad, in 64bit Windows 7.
I have built an Eclipse RCP application in Indigo (3.7.1.), 32-bit version.
The only "Javas" I have on this machine is a 1.6.29 32bit JRE, and a 1.6.29 32bit JDK. I've installed these (perhaps in false assumption) to be able to build for 32bit systems, and not screw things up by building on a 64bit machine.
Seems I was wrong: when I export the application (as Eclipse product) I get the dreaded Java exit code=13:
I am sure this is somehow to do with the combination of 32bit software on a 64bit system (if you can prove me wrong, even better!).
Does one of you know how I can set this up properly and still be able to build for win32?
Again, many thanks!
UPDATE
I have installed 64-bit Eclipse 3.7.1, and JRE 1.6_30 + JDK 1.6_30, both 64-bit versions. However, the error remains! I think this might either be a bug, or I'm doing something else wrong.
First of all, here is the error message:
For this build, I didn't use the Delta Pack but instead added the RCP SDK Software Site to the target definition, choosing the option "include all environments" (or similar).
Also in the target definition, I set the target environment to win32 (OS and WS) and x86_64 (arch). Furthermore, I set the Environment to use the default JRE.
In the product configuration, I set the Execution Environment to JavaSE 1.6, and set the JRE to be packaged.
Also, here's my eclipse.ini:
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
Any ideas?
I would recommend you to install everything as 64bit or 32bit system. That's a common problem with eclipse and I haven't found a better solution.
The Eclipse website tells me that
"Exit code 13 is returned from Main when it wants the launcher to display an error message. Generally, the error message will just be "an error has occurred, check your log file". Look for a log file in your configuration directory."
Some of these errors have been caused by not having the correct java version installed (Cannot run Eclipse; JVM terminated. Exit code=13), while others seem to have been caused by a "#" character in their eclipse directory (http://www.eclipsezone.com/eclipse/forums/t105198.html).
Maybe one of these reasons causes the crash.
Seems this had nothing to do with 32-bit vs. 64-bit and everything with my lack of experience. The product configuration simply wasn't set up correctly. I've bypassed this by creating a new one which uses the automatically created plugin run config from when you start the application via the "Launch an Eclipse application" link in Eclipse itself.
For those who come across a similar problem, here is how it can be done.
Launch the application via "Launch an Eclipse application"
Go to Run > Run Configurations... and memorize the name of the run configuration
Create a new Product Configuration, and choose "Use a launch configuration:" in the wizard. From the dropdown list, choose the run configuration you have memorized in step 2.
Give the new product configuration an ID, Version and Name, and add further info (e.g., in the Product Definition section) as needed.
Synchronize and Launch from within Eclipse to see if everything works fine.
Export and be happy.
Install all in 64bit.
Then to run (emulate) your Eclipse in 32bit
Just: insert an argument in:
Run Configurations... -> Arguments (tab) -> Program arguments : Type -d32
Old question but it seems worth answering. I just had this problem with an RCP based on features. It turned out that I was exporting the RCP with the feature projects closed. When I opened them and exported the product again, everything worked fine.
try moving the project to the root of the drive
c:\test\eclipse\
solved:D
1. check the operating system is it 32 bit or 64 bit.. but i think its not problem on my computer because i am using 32 bit jdk and 32 bit eclipse on my windows 7 64 bit.
2. if u still have problem ... try to move eclipse to C:/ its work for my friends.. with problem returned error 13
I am using eclipse 3.5 (cocoa build) on Macos 10.5 with Java 1.5.0.19.
I just have 3 java files opened
1 files ~ 2000 lines
the other 2 are ~ 700 lines.
But when I switch from 1 file tab to another, eclipse takes a long time (~ 20 seconds) to switch to another tab.
I have already change the eclipse.ini to
more eclipse.ini
-startup
../../../plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.0.0.v20090519
-product
org.eclipse.epp.package.jee.product
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=512m
-Xms128m
-Xmx1024m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
Is there any way to make eclipse 3.5 more speedy?
Thank you.
I switched this line in the eclipse.ini file (found inside the eclipse application package):
-Dosgi.requiredJavaVersion=1.5
to
-Dosgi.requiredJavaVersion=1.6
and tab switching was speedy again.
Go with the 32-bit Cocoa release. The 64-bit won't help IMHO. It really works great on my 2.4 GHz MBP. I usually have about 30 files open, some fairly large, never experienced what you describe.
Try to get a new plain-vanilla 32-bit Cocoa distro, don't modify anything and check if there's an issue. It could be a rogue plugin, too. Do you have any installed?
Check you heap status. Open the Eclipse preferences, in the very first preferences page there's a "show heap status" option. You might be running low on memory. Check the swap status of your machine using the activity monitor - if it swaps a lot I'd recommend shutting down other applications. In general, I recommend 4 GB RAM for development machines.
I know this is kind of late to the game, but I found that changing the permissions to ~workspace.metadata.plugins\org.eclipse.e4.workbench to deny myself access stopped the slow-down issue.
Seems that Eclipse (4.2.0) writes out a corrupt settings file every so often, and when it's loaded in at startup again it slows everything down as it's constantly throwing errors internally. Changing the security on that directory so that Eclipse can't write to it is a kind of "fix"! It does mean that each time Eclipse is started it's back to its default settings, but if speed is more important, I think it's a worthwhile sacrifice.
There are now patches for Juno to begin addressing this issue. See comment #212 on bug 385272 for information on how to update your installation. If you wait a little longer you should find these fixes in the Kepler milestone on 12/21/2012.
(I believe the other suggestions posted here, e.g. increasing memory or tweeking various startup params or prefs might have some positive effect on performance, but the underlying problem is threads run amok as described in the bug report.)
This might be the bug that was referred to. https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229
switching to 1.6 really helps.
This is the link to locate eclipse.ini file for mac
http://wiki.eclipse.org/Eclipse.ini
This eclipse bug report is spot-on with the behavior you describe. (I had the same experience using a new Juno installation on a beefy XP machine.)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272
The most useful part of the bug report was in comment 29, which suggests creating a new workspace. The easiest way to do this is:
1) exit eclipse
2) rename .../path/to/workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi
(e.g., append ".old")
3) start eclipse
I believe changing -Dosgi.requiredJavaVersion=1.5 to 1.6 may help only incidentally, if at all.
Increase the memory limits in eclipse.ini seems to have fixed this for me - not sure if it will stay fixed though
FROM:
-vmargs
-Xms40m
-Xmx512m
TO
-vmargs
-XX:MaxPermSize=512m
-Xms256m
-Xmx784m
ALSO - if you came from aptana3 and imported your project - You need to do this
Click Project Properties
Go to "Builders"
Make sure there are no "Missing Builders" If there are, uncheck them - I had two left over from aptana when I imported my project (com.aptana.ide.core.unifiedBuilder AND com.aptana.editor.php.aptanaPhpBuilder)
---- UPDATE ----
It was fixed - but not for the reasons I thought. My SVN was no longer recognized by eclipse. As soon as I hit 'share with team' and reconnected it the tab-switching issues reappeared. I'm going to try and figure out if It's an svnKit vs JavaHL problem - I'm not sure which connector I picked when I setup eclipse this time.
If you want confirm this is your issue trying disconnecting from the SVN (Team->disconnect) and restarting eclipse
This is an known issue.
Since you are using JDK1.5, you can try the Carbon variant.
I experience the same issue using OS X 10.5.7 and Eclipse 3.5.2 on a fairly low end machine (early 2006 iMac with 1.5GB). Right after I start my machine however, everything is really snappy. I can even launch JBoss AS and there is still no slow-down. I monitor "Swap used" in activity monitor, and it stays at 0 bytes swap used.
Then, I launch something else, like iTunes and mail or switching to another account.
Things become slow then, which is expected, and I see "Swap used" increasing. Eclipse slows down to a crawl, and working with it is near to impossible.
Then I logout the other account, close down all other apps that I opened, so the state of my machine is basically the same again as when it was still fast. BUT... it stays dog slow! Even though I closed all the other apps, "Swap used" in activity monitor only decreases a little (from ~1.2GB to ~700MB). Just switching tabs between 2 very simple Java files takes up to 20 seconds, meanwhile I see in activity monitor that the CPU usage goes up to a solid 100%.
There definitely is something strange going on here. This does not seem like normal behavior. It is as-if Mac OS X goes into a 'slow mode' when I demand too much resources from it, but when the resources are there again it fails to recover.
Highly annoying!
If I reset the machine and open the exact same working set again (Eclipse with the same 2 files open, JBoss AS started in debug mode, Safari with 1 window) everything is really fast again.
I can now more or less confirm that the problem is really with Eclipse 3.5.
I've run Eclipse on a much more powerful Mac, a 27" core I7, 2.93Ghz with 8GB ram and a SSD running OS X 10.6.4. Initially this was extremely smooth and snappy, but after an up time of a dozen hours or so, Eclipse suddenly began to slow-down again. I had very little to almost nothing running in the background. Just Eclipse (32 bits, given it 1.5GB memory), JBoss AS and Safari.
A simple tab switch would take a few seconds and meanwhile I noticed the CPU load on one core going to 100%. The same happened with switching perspectives and various other operations.
When I restarted only Eclipse, everything was completely fast again. This happened a couple of times.
For me the issue was the SVNKit connection integration to the Juno version of Eclipse. I am doing Android Development using the Juno version of Eclipse and when I turned on the SVNKit Team Integration I got the following issues described:
Very slow switching between code files in the Eclipse IDE.
Extra large gap and space in the tool bar between the print and Android SDK Manager icons.
For me... I turned off the following settings under Window->Preferences->Team->SVN under the View Settings... there was a setting for "Show synchronize info incrementally"... I turned that off and the switching between files improved.... but there is still a delay versus NOT having SVN connected.
Without SVN connected... the switching between files is normal.
I had Java 1.6 in the Eclipse.ini
I did not change the settings for memory.
TL;DR for the bug thread:
http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation#Resolution
Worked for me.
The original problem of slow switching between tabs has reappeared in Eclipse Neon (4.6.2 only?) using the Dark theme.
Solution: disable themed scrollbars in e4-dark_win.css (bottom of file):
StyledText {
swt-scrollbar-themed: false;
[...]