We Keep Coding

Chef Java malloc issues

I have having a strange issue installing a piece of software that uses a ANT based installation script executed from a JAR using the Oracle JVM (1.8) 64bit.
The issue only appears to happen when the JAR is executed via a Chef run. Note I am using Chef-zero to converge.
The issue appears to be with the JVM being able to allocate enough
memory to execute.
The issue ONLY appears when Chef executes the JAR, via the OS console
itself and CMD everything is fine.
We have been installing this software for years and have not seen
this issue ever prior, until we started using Chef.
There are different errors depending on what I try to set the HEAP values to (note never have we had to set any HEAP options to install previously).
One such error is :
Unable to allocate 65536KB bitmaps for parallel garbage collection for the requested 2097152KB heap.
I have also seen other similar errors depending on the values I provide for Xms and Xmx similar to the above.
This has only been seen on Windows systems and only on certain VirtualBox images.
Some downloaded from net (vagrant) work fine, some fail with above
error.
Any image I build locally fails.
Chef Scripts I have tried (note the java options I have tried many combination, this is latest try):
execute "Install Xstore: #{build_file}" do
command "#{java_home}\\bin\\java -jar #{build_file}"
cwd install_workdir
environment ({ 'PATH' => "c:\\Program Files\\Microsoft SQL Server\\Client SDK\\ODBC\\130\\Tools\\Binn\\;#{ENV['PATH']}", 'JAVA_TOOL_OPTIONS' => '-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=c:/xstore/log/dump.bin' })
not_if { ::Dir.exist?(xstore_install_dir) }
end
ruby_block "Install Xstore: #{build_file}" do
block do
stdout, status = Open3.capture2("#{java_home}\\bin\\java -jar #{build_file}", chdir: "#{install_workdir}")
puts stdout
end
end
Some specs:
Chef-client: 14.14.29
Guest VM: Windows 10, Windows 10ltsc - 64bit
Host: PopOS Linux 19.10
VirtualBox version: 6.0.14
Java (guest): 1.8.0_241
Host Ram 32GB, VM Ram upto 16GB same issues (ram is always 90% free on guest taskmanager, paging file set to System, tried fixed as well)

Segmentation Fault only on Ubuntu 10.04 32bit because of too small stack size

I have a Java application which uses several native libraries through JNA.
The application works fine on many different systems. However, on Ubuntu 10.04 LTS - 32bit when I close the application a segmentation fault occurs.
64bit works fine and the error does not occur on other 32bit distributions. Windows works fine too.
The segmentation fault occurs in the delete function of glibc within an empty destructor.
The problem is solved, if I increase the maximum stack size of the JVM to 32mb
(e.g. java -Xss32m ...)
Does anyone have an idea why this error only happens on Ubuntu 10.04 32bit?
I have tested several distribution within a VM.
I am using Java 8 and the default maximum stack size is 4MB.
I dont know if this is relevant to the JVM, but ulimit -s is 8MB.

Eclipse won't start with Xmx set to 1024m anymore, though there is enough memory

My Eclipse (or, more specific, Spring Tool Suite) version is:
Version: 3.6.3.RELEASE
Build Id: 201411281415
Platform: Eclipse Luna SR1 (4.4.1)
It worked fine, until recently, when I started getting the following error after opening Eclipse:
Error: Could not create the Java Virtual Machine
Error: A fatal exception occured. Program will exit.
My start options include -vm <path to javaw> -vmargs -Xmx1024m -XX:MaxPermSize=256m, I am using jdk1.7.0_79, the 32 bit version, on a 64bit Windows.
I discovered, when setting -Xmx to 768m, Eclipse will start most of the time. I also noticed that starting eclipse began to fail when I installed the MySQL service; if I deactivate it, the Task Manager shows me I have roughly 4gb of 16gb of RAM consumed; with MySQL running, that value increases to 5gb.
What is the reason, when there are 5gb consumed and roughly 11gb of RAM left, that no JDK can be created, and is there a known workaround?

It is likely because of lack of virtual address space. Remember that 32-bit processes have only 2GB of virtual space, which is needed for:
application code
DLLs, both application DLLs and shared DLLs like hooks
java off-heap needs: code caches, buffers, etc.
java heap itself
So, physical RAM is unrelated.
What likely happened?
Eclipse grew heavier so JVM needs more off-heap to function
What you can do?
Uninstall unneeded plugins, shut down your antivirus or other software that could intervene with Eclipse, use 64bit java. 64bit apps are faster on modern processors + 64-bit java uses compressedOps so it could make sense.

In the past i had simlar issues, but no solution. I reached the limit with -Xmx1500m.
See also Maximum Java heap size of a 32-bit JVM on a 64-bit OS.
Is using the 64 bit Version of the JDK no option?

Jenkins is failing to start a 32-bit JVM for a job

I'm running Jenkins 1.557. I have a job that I need to be built with a 32-bit version of JDK 1.6_u45. I have that version properly configured in my job's JDK setting. However, when I attempt to run the job, I get the following error.
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
If I switch the job's JDK setting to a 64-bit version, the JVM is able to be created and it runs as normal. The server has 8GB of RAM available, and I've even attempted to pass in a string parameters of JAVA_OPTS=-Xms512m -Xmx1024m & ANT_OPTS=-Xms512m -Xmx1024m to the build, but to no avail.
Please note this is not a duplicate of Could not reserve enough space for object heap. If I attempt to build the project at a regular command line (Windows environment variable JAVA_HOME pointing to the same 32-bit JDK installation as the Jenkins attempt), the project builds. This is seemingly a Jenkins specific issue.
My guess is somewhere in Jenkins (or in some hidden Jenkins config file) the JVM heap size is being set too large for the 32-bit JVM, but I can't seem to pinpoint where that is being set. I've checked the jenkins.xml in JENKINS_HOME but the heap size is not being set in the arguments tag.

Answer
Try a lower max heap (-Xmx) value, such as -Xmx900m or -Xmx800m and see if this solves the problem.
From my experience, Jenkins honors your ANT_OPTS environment variable and does not mess with it. I use Jenkins Freestyle Jobs that launch Ant personally and I've always set ANT_OPTS, MAVEN_OPTS, ... separate from Jenkins and it has never changed anything. Make
Better yet, start with a much lower value like -Xmx512m (I would use ANT_OPTS, which Ant uses for this and not bother with JAVA_OPTS). If it still fails to initialize, OK, then maybe I'll entertain that Jenkins is doing something. If not, there's your answer.
At the root, I believe this is the same problem as the duplicate question you linked, it just reproduces in more limited circumstances. More details below.
Background
Just yesterday, on a coworker's machine I saw -Xmx1024m fail in a standard command window with the same message with 32-bit Java. Just because it works in one situation does not mean it will always work.
On Windows, 2GB max address space per 32-bit process severely limits the maximum heap size you can set in Java since Java requires that the entire object heap be allocated in one contiguous block. Especially in modern versions of Windows that use ASLR (Address Space Layout Randomization), you simply can't be guaranteed large heap sizes for 32-bit processes...even 1024m can sometimes be too large since in Java the heap must be contiguous. Picture a horizontal line from 0 to 2GB, and then a [1GB] chunk taking up 50% of the width. Now insert 50 random DLLs into that 2GB horizontal line in random locations...now try to fit your [1GB] chunk without hitting a dot.
Not exact, here's my poor man's diagram of the address space:
0 [________________________________________] 2GB
_ is unallocated, available, | is occupied
Now with DLLs:
0 [__|_______|___________________|___|_____] 2GB
You need to fit this (including edges) into that address space:
[__________________]
Maybe it barely squeeks in...now let's add one more blip
0 [__|_______|_____________|_____|___|_____] 2GB
[__________________]
Suddenly it won't fit.
It's possible there is an extra DLL being loaded by Jenkins that is fragmenting your address space just slightly more so that 1024m fails under Jenkins but not in a standalone window. Since your goal is to run it under Jenkins, I don't see a clear solution to that other than to reduce your max heap size since your goal is to run a 32-bit build. In the Windows XP days, it was common to get -Xmx1300m or so to work, but apparently even -Xmx1024m is a stretch on Windows 7 and Windows 8 (in some cases, anyway). It really seems like the most likely case is...you're trying to set the heap too big for 32-bit.
Verification
If this really isn't the problem, or if you don't believe me, you can verify what Java memory settings your 64-bit version of the build is actually using (namely because it has to actually start to see the settings while it's running). Since your other build is failing to even start, I'm not sure you can use this method there. Whether Jenkins is doing something or not, whether you tell your job to use a 32-bit JDK or 64-bit JDK, if it's reading ANT_OPTS it should be the getting the same end result -Xmx value from that environment variable for both builds (the one that works (64-bit), and the one that fails). You can use a utility included with the JDK to do this called jconsole. From the bin directory of your JDK installation, run 'jconsole'. Or, if you have %JAVA_HOME%\bin in your PATH, you should be able to directly launch jconsole.
This will start a graphical client allowing you to select from any Process IDs (PIDs) that have a JVM running in them, this list should be pretty short in most cases. Select your Ant process and connect to it. Switch to the VM Information tab, and you will see the heap settings and other VM arguments that the JVM is using.
You will see a "VM Arguments" section, which should include your -Xms and -Xmx settings, but also "Maximum Heap Size", which will probably display in kilobytes.
Bonus knowledge, but not directly relevant since you've stated Java 6. If this were Java 7 or later, you could use:
jcmd
to obtain the PID, then:
jcmd <PID> VM.arguments
to see the VM arguments for the Java process with the PID you specified. jcmd being another utility that comes with the JDK. This, for me at least, displays the raw bytes value so you'll need to translate in your head. (it won't show -Xmx1024m it will show -XX:MaxHeapSize=1073741824)

“Error occurred during initialization of VM; Could not reserve enough space for object heap” using -Xmx3G

First of all, I have a box with 8gb of ram, so I doubt total memory is the issue.
This application is running fine on machines with 6gb or less.
I am trying to reserve 3GB of space using -Xmx3G under "VM Arguments" in Run Configurations in Eclipse.
Every time I try to reserve more than 1500mb, I get this error:
“Error occurred during initialization of VM; Could not reserve enough space for object heap” using -Xmx3G
What is going on here?

Could it be that you're using a 32-bit jvm on that machine?

Here is how to fix it:
Go to Start->Control Panel->System->Advanced(tab)->Environment Variables->System
Variables->New:
Variable name: _JAVA_OPTIONS
Variable value: -Xmx512M
Variable name: Path
Variable value: ;C:\Program Files\Java\jre6\bin;F:\JDK\bin;
Change this to your appropriate path.

This is actually not an Eclipse-specific issue; it's a general
Java-on-Windows issue. It's because of how the JVM allocates memory on
Windows; it insists on allocating a contiguous chunk of memory, which
often Windows can't provide, even if there are enough separate chunks to
satisfy the allocation request.
There are utilities that will try to help Windows "defrag" its memory,
which would, in theory, help this situation; but I've not really tried
them in earnest so can't speak to their effectiveness.
One thing that I've heard sometimes that might help is to reboot Windows
and, before starting any other apps, launch the Java app that needs the
big chunk of memory. If you're lucky, Windows won't have fragmented its
memory space yet and Java will get the contiguous block that is asks for.
Somewhere out on the interwebs there are more technical explanations and
analyses of this issue, but I don't have any references handy.
I did find this, though, which looks helpful: https://stackoverflow.com/a/497757/639520

First the JRE of 32bits can't use more ~1.5Gb of ram. So if you want more, use a 64bits JRE.
Second, When a new JVM starts, this sum the -Xmx property of the all JVM that are running, and check if there is enough memory left on the system to run at their own -Xmx, if is not enough then the error occurs.

I was using Liferay with Tomcat server from eclipse IDE.
I was stuck with this same error on click on server start up.
Double click on server from eclipse.
it open up Server Overview page. Updated memory arguments from -Xmx1024m -XX:MaxPermSize=256m to -Xmx512m -XX:MaxPermSize=256m.
Then it was working for me.

Make sure that Eclipse is actually running the same JVM you think it's running. If you use java in your web browser ever, you likely have a 32-bit version floating around too that might be taking precedence if it installed or updated lately.
To be absolutely sure, I recommend adding these two lines to your eclipse.ini file at the top:
-vm
C:/Java/jdk1.6.0_27/bin
...where on my machine C:/Java/jdk1.6.0_27/bin where the JVM I know is 64-bit is located. Be sure to have the bin folder there.
(As a bonus, on Windows 7, this also allows you to actually "pin the tab" which is why I had to do this for my own usage)

This is the issue of Heap size. Edit your .bat (Batch file). It might be showing Heap size 1024. Change it to 512 Then it should work.

Just put # symbol in front of org.gradle.jvmargs=-Xmx1536m in gradle.properties
# org.gradle.jvmargs=-Xmx1536m

I also had the same problem while using Eclipse which was 32 bit and the JVM used by it was 64 bit.
When I routed the Eclipse to 32 bit JVM then it worked

I know that i am a bit late, but here my answer comes:
I just installed the Java online Version from Oracle(not the offline 64-Bit one).
After having added the JAVA_HOME ENV variable, it just worked!
Hope I could help :)

Probably you are trying wrong options anyways.
I got a similar error with supporting error log:
Java HotSpot(TM) Client VM warning: ignoring option PermSize=32M; support was removed in 8.0
Java HotSpot(TM) Client VM warning: ignoring option MaxPermSize=128M; support was removed in 8.0
Im my case, the software did not support java 8 yet(script was using old JVM arguments) but I had had java 8 by default.

One of the reason for this issue is no memory available for Tomcat to start. Try to delete the unwanted running software from windows and restart the eclipse and tomcat.

Solution is simple. No need to go deep into this issue.
If you are running on 64bit machine then follow below steps:
Unistall 32 bit java first (check in C:\Program Files (x86) for its existence)
Install the newer version JDK kit 64 bit (includes JRE)
Set the environment path (To avoid conflict error if you have two different 64bit JRE)
Check in command prompt by typing javac command.
Restart / Done
You can have two different Java installed but don't forgot to set path.

Please set JAVA_OPTS=-Xms256m -Xmx512m in environment variables, it should solve the issue, it worked for me.

Find out if you are using a 32bit version or 64bit version of Java. To know that use the command
java -version
The 3rd line of the output should give you if it 32bit or 64bit.
If it is 32bit uninstall and install a 64bit version.