RESOLVED check below for solution.
I'm using Intellij Idea 2017.2.2. Below is my intellij Specs.
My Intellij would only occasionally fail a maven build or a jboss server start with the error
Error occurred during initialization of VM
Could not reserve enough space for 1048576KB object heap
If I were to run the maven build with the vm args of
-Xms512m -Xmx1024m
The build would fail 9 out of 10 times (not exactly every 10th, but just randomly). But on the 10th time it would work. I simply have to keep pressing the install button until it works.
This was a major problem before was that if I don't specify the vm args then the build would go about halfway then fail on running out of java heap space.
The same exact behavior can be observed for my jboss server (JBOSS6.4 - 7.5.0.Final redhat 21), where the server would fail to start 9 out of 10 times. Then start up as randomly as it does not.
Specs
IntelliJ IDEA 2017.2.2
Build #IU-172.3757.52, built on August 14, 2017
Licensed to -----
Subscription is active until May 31, 2018
JRE: 1.8.0_152-release-915-b10 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 7 6.1
What I tested
I upgraded from Intellij 2017.1 to 2017.2 and the behavior did not change.
I also tried to do the same on Eclipse which also did not help.
Clean restart of PC, then close all the unnecessary apps, open intellij do a maven build and yet it fails, but a few more clicks and it works inconsistently as usual. (note at this moment only 6gb out of 16 is used, there is no way there is an insufficiency with memory)
*Edits
This PC have 16 gb of ram. While the fails are happening about 9.5GBs are being used at that moment.
Ultimately I was able to resolve the issue by updating the proper JDK.
My project was picking up on an incorrect JDK and hence was running the 32 Bit as opposed to 64 bit JDK.
Simply added the correct JDK under File > Project Settings.
It seemed that my project never required that much memory before, but once the need had risen, it seems that a 64 bit became required.
I have solved this problem by changing the build settings in Intellij.
Please follow the below steps.
For SBT:
1. Go to File -> Settings -> Build, Execution Deployment -> sbt
2. Change the value of Maximum heap size, MB to your available memory. Ex. 512
(Previously this value was 1536, due to this I faced the problem)
For Maven:
1. Go to File -> Settings -> Build, Execution Deployment -> Maven -> Importing
Change the value of VM options for importer to your available memory. Ex. -Xmx512m
I had to do the following options to get it pass the error.
Spec used: IDEA IntelliJ 2019.3.5 (Community Edition)
Increase the memory in IntelliJ VM Options
Step 1:
Go to Help -> Edit Custom VM Options
Step2: Change the Heap sizes as given below
Run the app with increased memory by setting the VM options
Run -> Edit Configurations
My issue was resolved by installing Visual C++ Redistributable Packages:
https://aka.ms/vs/16/release/vc_redist.x64.exe
Related
I have imported a SBT project into IntelliJ(version 14). When I am trying to run something in the terminal, the console output is giving me "java.lang.OutOfMemoryError: Java heap space".
I have tried increasing the size (Xms2048m, Xmx2048m) in *.vmoptions, and also in the IDE build settings of SBT project. I have restarted my machine as well. Nothing is working out.
Any more inputs on it other than the things I have tried ?
P.S: I am running the project through the activator. When I am doing it from IntelliJ command prompt it's throwing me the error, but when I run the activator from windows command prompt, it is successfully running the application.
You just asked your IDE:
-Xms2048m - ask VM to allocate 2048MB (2GB) heap on start
-Xmx2048m - limit heap to 2048MB
The reason could be:
You tried to exceed 2048MB
Allocating 2048MB on start was not possible (you probably just went out of RAM)
System thought so fast allocation was a malware.
I think you will need to provide the memory settings as parameters to the command you are running on the console.
To the best of my knowledge any parameters set inside IntelliJ will only be for use of IntelliJ itself, and when you run the project from the SBT window (I am assuming it works like the maven window).
Also as far as I know the terminal window in IntelliJ is just a "pass through" to the underlying console of the host system.
Not sure you need it, but this seems to be a good explanation of the memory settings, and links to duplicate answers: What are the Xms and Xmx parameters when starting JVMs?
I was getting a similar issue while building the project in IntelliJ what worked for me is to update the build memory size in settings as below:
Settings (or Preferences) -> Build, Execution, Deployment -> Compiler -> Shared build process heap size (Mbytes)
I have a problem starting Intellij IDEA (15.0.3) in 64 bit mode. When clicking on the idea6.exe I get this error (Failed to create a JVM error code -6):
This is my configuration:
System:
Windows 7 - 64 bit - 16GB RAM
System Variables:
IDEA_JDK_64: C:\Program Files\Java\jdk1.8.0_74
JVM_HOME: C:\Program Files\Java\jdk1.7.0_79
(1.7 version is needed for my dev activity)
vm options: idea64.exe.vmoptions left as default
As a trial: I've tried various combinations like system variables pointing to the same JDK path or also to increase -Xmx value in idea64.exe.vmoptions, but the error is still there.
What can the root cause be?
Thank you very much.
I solved problem in my case by deleting file C:\Users\username\.IdeaIC2016.2\idea.exe.vmoptions, because I created it before to customize VM options. File can have name idea64.exe.vmoptions if you overrode options under 64-bit version of Intellij IDEA.
Tracked it down to a mis-typed VM option in the end.
Somehow one of the lines in my idea64.exe.vmoptions file has been mis-typed. Instead of -XX:UseParNewGC I had -XX:USeParNewGC (note the unwanted extra capital letter).
Correcting that fixed the problem - so check your .vmoptions file for typos if you get the -6 error on startup.
And note that there may be several copies of this file. The default is in the installation folder (eg "Program Files (x86)\Jetbrains\Intellij 2016.1\bin\idea64exe.vmoptions"), but if you select "Help...Edit Custom VM Options" in the IDE it will create an override file in \Users\.IntellijIdea2016.1\idea64exe.vmoptions
I experienced the same issue with IntelliJ IDEA 2016.1.3 on 64bit Windows 7 with JDK1.8.0_92.
Executing idea.bat instead of idea.exe worked for me.
I think issue caused because you are using 32 bit launcher, and it has limitation as 4G for RAM.
So, if you will change value "-Xmx" to 2048 in c:\users\XXXXXX.WebStorm2016.3\webstorm.exe file -> this should help. Otherwise -> delete this file and wait when WebSrotm propose you to change it from IDE
Note: there are also webstorm.exe and webstorm64.exe files in your c:\Program Files
Had same problem, any option in studio64.exe.vmoptions led to this window.
Fixed by changing entry in PATH, it had old JDK folder, which pointed to different Java installation(Java 7) than JAVA_HOME(Java 8), after replacing it — Android Studio started normally with entries in studio64.exe.vmoptions file.
For me, using Intelli J Idea Community Version 2017.3, I found the idea.exe.vmoptions file in C:\Users\${UserName}.IdeaIC2017.3\config. I had increased the JVM Heap Memory to 4096MB from 512MB due to an earlier crash (-Xmx4096m). Changing to 1024MB seemed to do the job.
For me it worked once i deleted the vmoptions file created under the C:USERS.IntelliJIdea2017.2\config folder.
Now that OSX Maverick works with memory different (so it seems and from what I've read), when I run Java as a separate JVM (Ant/JUnit/etc.), I often get OutOfMemory exceptions as it bases the max heap on memory available which is usually close to zero (because that's apparently how Maverick works?). I know I can set the max heap space using the -Xmx argument for a run or external tool configuration in Eclipse, but that is a pain when I have several possible configurations that can be run.
I believe I would have to run in a separate JVM so my configurations don't get polluted with Eclipse classpath JARs and to a smaller extent, so the Eclipse JVM doesn't get polluted with configuration runs and all the class loading that goes on.
Is there a global setting to set the max heap available for all JVMs launched by Eclipse? For Ant, I tried setting ANT_OPTS in my environement to "-Xm1024m", but that setting doesn't seem to take when running Ant through Eclipse. If I run Ant from the command line directly, it does seem to work (or at least I didn't get an exception). When running Ant in verbose+debug mode in Eclipse, I do see "Setting project property: env.ANT_OPTS -> -Xmx1024m" so I know the variable is set.
I ran Java VisualVM to get a better idea what is going on, this is what it has:
JVM: Java HotSpot(TM) 64-Bit Server VM (23.25-b01, mixed mode)
Java: version 1.7.0_25, vendor Oracle Corporation
Java Home: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre
JVM Flags: <none>
Main class: org.eclipse.ant.internal.launching.remote.InternalAntRunner
You can configure JVM arguments for an Eclipse Ant build in the Run > External Tools > External Tools Configurations dialog in the JRE tab.
Note that the default is actually to run Ant in the same JVM as Eclipse (which makes some additional Eclipse tasks available).
Running VisualVM made me realize Eclipse was still using 1.7.0_25 and not 1.7.0_45 which is the latest I have installed. Once I updated Eclipse to use 1.7.0_45, I no longer have the issue as the VM does indeed use 1/4 of total memory. Would be nice to know for sure, but it seems like build 25 had a bug or something.
I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?
The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer
The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.
"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!
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