How to Solve "Java.Io.Ioexception: Error=12, Cannot Allocate Memory" Calling Runtime#Exec()

How to solve java.io.IOException: error=12, Cannot allocate memory calling Runtime#exec()?

What's the memory profile of your machine ? e.g. if you run top, how much free memory do you have ?

I suspect UnixProcess performs a fork() and it's simply not getting enough memory from the OS (if memory serves, it'll fork() to duplicate the process and then exec() to run the ls in the new memory process, and it's not getting as far as that)

EDIT: Re. your overcommit solution, it permits overcommitting of system memory, possibly allowing processes to allocate (but not use) more memory than is actually available. So I guess that the fork() duplicates the Java process memory as discussed in the comments below. Of course you don't use the memory since the 'ls' replaces the duplicate Java process.

playframework - IOException unable to allocate memory

Since this is a general javac error, I doubt that it is Play related. Most likely you really ran out of memory.

Java HotSpot(TM) 64-Bit Server VM warning

There is insufficient memory for the Java Runtime Environment to continue.

Native memory allocation (malloc) failed to allocate xxxxx bytes for committing reserved memory.

Possible reasons:

  1. The system is out of physical RAM or swap space
  2. In 32 bit mode, the process size limit was hit

Possible solutions:

  1. Reduce memory load on the system
  2. Increase physical memory or swap space
  3. Check if swap backing store is full
  4. Use 64 bit Java on a 64 bit OS
  5. Decrease Java heap size (-Xmx/-Xms)
  6. Decrease number of Java threads
  7. Decrease Java thread stack sizes (-Xss)
  8. Set larger code cache with -XX:ReservedCodeCacheSize=

If you are on Java 8 or later, please also see this question: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize

Memory Allocated to Command Line Program Invoked through Java

The javadoc for Runtime.exec states that the command will be started in a separate process. Hence, the command itself will be run in its own process with its own memory and will not use any of the JVM memory.

However of course the method also returns a Process object, which itself will use a bit of the JVM memory, but that will be just a few variables to keep track of the process that was launched, so unless you start tens of thousands of processes in parallel this should not be an issue.

Jboss Seam Interpolator: could it be use for execute command (java.lang.Runtime.exec)?

Are you sure that it is YOUR code trying to run "ls" on your server? If not, it looks like someone is trying to exploit this problem of Seam 2. In this case you should upgrade to Seam 2.2.2.Final

Does JNA system() avoid a fork

Probably not. The implementation of system() that you're calling is almost certainly using fork() itself -- the C implementation will look something like:

int system(const char *cmd) {
if (fork() == 0) {
execl("/bin/sh", "-c", cmd);
_exit(1);
}
int result;
wait(&result);
return WEXITSTATUS(result);
}

A more feasible solution would be to maintain lines of communication (e.g, pipes) to a small external process which can spawn off subprocesses for you. Android does something very much like this; the external process is known as the "zygote".

error executing aapt, all of the sudden

The actual problem seems to be that the aapt process is asking for an unreasonable amount of memory. Memory that my system with an SSD HD and (thus) no swap (but 4GB of RAM) does not have, next to the already big eclipse process.

The solution is to set:

echo 1 > /proc/sys/vm/overcommit_memory

Read the articles below, but my understanding is that the linux kernel has a flaw, and is imperfect in predicting how much memory a new process will need. This flag allows the system to start any process, regarding how much memory it is asking. Note that in practice aapt will never use this much memory. It seems the size of the eclipse process (in my case for example 2GB) is the estimate and this is added to whatever RAM is in use (2GB eclipse + 0.5GB other), which exceeds my 4GB RAM. Aapt would only use a fraction of the 2GB but the calculation fails.

The downside of allowing this overcommit apparently is that the kernel has no clean solution when you are running low on memory, and will just kill processes.

Another solution is to use a swap, in my case a swap file as I did not foresee a swap partition, and then preferably with a very low swappiness. Your linux manual should tell you how, but in summary (this is only for a quick test, you should set up your /etc/fstab instead):

dd if=/dev/zero of=/swap bs=512 count=4M # = 2GB swapfile
mkswap /swap
swapon /swap

echo 0 > /proc/sys/vm/swappiness

Setting the swappiness so low makes it so that the swap is in reality never used. This is also the biggest downside of this solution. You'll have a 2GB file on your harddisk that you'll never use, except to satisfy the kernel's calculations (and maybe a rare extreme low memory, not sure how 0 swappiness works?). It is said to be a bad idea to use a swap on an SSD as the many writes will shorten the lifetime of the SSD.

The following articles led me to the solution.

How to solve "java.io.IOException: error=12, Cannot allocate memory" calling Runtime#exec()?

http://webcache.googleusercontent.com/search?q=cache:2NSdg-wIVsAJ:wiki.apache.org/cassandra/Operations+java.io.IOException+insufficient+system+resources+no+swap&cd=4&hl=nl&ct=clnk&gl=be&lr=lang_en|lang_nl

Note that it is not aapt that is at fault here, nor are the Android dev tools. I could have seen this problem anywhere. I do think however that due to the gigantic (and increasing) size of the eclipse toolkit, coupled maybe with some implementation details, such as the use of fork()?, this problem has a very high likelihood of surfacing here, also for other people with SSDs.

running a .sh file inside grails server

Sounds like you're not alone:

How to solve "java.io.IOException: error=12, Cannot allocate memory" calling Runtime#exec()?

Above SO thread provides a (possible) solution to your problem, give it a shot.



Related Topics



Leave a reply



Submit