Develop Reference

java.lang.Error: Invalid memory access on 32 bit Windows

I have JNA wrapper for a C DLL. It works fine, except when used on a Windows 32-bit system. Here is a simplified example:
int SetData(const wchar_t* data);
int SetId(const wchar_t* id, uint32_t flags);
I created JNA bindings as follows:
public static native int SetData(WString data);
public static native int SetId(WString id, int flags);
The first function SetData() works fine on both 32-bit as well as 64-bit Windows, but the second function crashes on Windows 7 32-bit.
I tried using NativeLong as suggested in other related posts, but it didn't help.
Here is the link to the repository:
https://github.com/cryptlex/lexactivator-java/blob/master/src/main/java/com/cryptlex/lexactivator/LexActivatorNative.java

Your mappings are correct: WString is the correct mapping for const wchar_t*, and int (always 32 bits in Java) is the correct mapping for uint32_t (always 32 bits), with a caveat about signededness that shouldn't matter when used as a flags bitmask.
I'm not sure where you read that NativeLong would be appropriate here. This is primarily intended for *nix native code in which sizeof(long) differs based on the OS bitness. Practically, it doesn't actually matter on Windows since LONG is always 32-bit, but it involves unnecessary object creation vs. a primitive.
The "Invalid Memory Access" error thrown by JNA is a "graceful" handling of native memory errors caught by Structured Exception Handling. All you really need to know is that either You are attempting to access native memory that you do not own or Your native memory allocation failed.
Debugging these errors always involves carefully tracking memory allocations. When is memory allocated? When is it released? Who (Java-side or native side) is responsible for this allocation? Your program is likely crashing at the point you attempt to copy data from the user-provided ID string to some native memory that your native DLL is accessing. So that points to two memory pointers you need to investigate.
Look at the memory where the ID string is being written. Find out when the memory for it is allocated. Ensure it is large enough for the string (should be 2x string length + 2 bytes for a null terminator) and properly zeroed (or a null byte explicitly appended). Verify all WinAPI calls use the correct (W vs. A) unicode version.
I tried adding LA_IN_MEMORY to the flags bitmask and got an error message "Either trial has not started or has been tampered! Trial days left: 30". This is apparently produced by the next line (IsLicenseGenuine()), meaning that the setProductId() call was successful.
Identifying what your native code does differently when the LA_IN_MEMORY flag is not set will probably be very helpful. It's possible the invalid memory access is associated with identifying the directory or file to be used.
There is a recent changelog entry for 3.14.9 involving this flag. Looking at that commit might give a hint to the problem.
There's another recent change in 3.15.0 involving auto-detection of a file on Windows which also may be suspicious given that LA_IN_MEMORY makes the problem go away.
When given an invalid key, the error message "43: The product id is incorrect." is returned, so the point in native code where unowned memory is being accessed is after this error check.
Trace what is happening with the ID string defined on the Java side. Given the constant definition of the string, the actual memory allocation is likely not a problem, but keep track of the native pointer to this string to be sure it's not inadvertently overwritten.
As you've noted in the comments, reducing the native memory allocation solves this issue, indicating you are hitting a limit. It turns out the default 32-bit Java native memory allocation for stack size (-Xss) is 320 KB. From Oracle docs:
On Windows, the default thread stack size is read from the binary
(java.exe). As of Java SE 6, this value is 320k in the 32-bit VM and
1024k in the 64-bit VM.
You can reduce your stack size by running with the -Xss option. For
example:
java -server -Xss64k
Note that on some versions of Windows, the OS may round up thread
stack sizes using very coarse granularity. If the requested size is
less than the default size by 1K or more, the stack size is rounded up
to the default; otherwise, the stack size is rounded up to a multiple
of 1 MB.
You could increase this limit to solve the problem or, as you've indicated in the remarks, lower your native allocation. You might wish to be more conservative than 300K as that only leaves a small amount for other use of the stack. You might also start smaller, check the return value for ERR_MORE_DATA and try again with a larger value. 300KB seems a rather huge amount to devote to registry values.
Note also that 32-bit Java has a total process memory size limit of either 2GB or 4GB, depending on the OS. If your Java heap allocation grows close to that limit, it reduces the native amount available to you. You can control how big the heap gets with the -Xmx switch and you can also ensure sufficient native memory allocation with the -Xss switch. Use these switches in a combination to avoid hitting the process size limit.

Setting a smaller JVM heap size within a JNI client application

I'm attempting to debug a problem with pl/java, a procedural language for PostgreSQL. I'm running this stack on a Linux server.
Essentially, each Postgres backend (connection process) must start its own JVM, and does so using the JNI. This is generally a major limitation of pl/java, but it has one particularly nasty manifestation.
If native memory runs out (I realise that this may not actually be due to malloc() returning NULL, but the effect is about the same), this failure is handled rather poorly. It results in an OutOfMemoryError due to "native memory exhaustion". This results in a segfault of the Postgres backend, originating from within libjvm.so, and a javacore file that says something like:
0SECTION TITLE subcomponent dump routine
NULL ===============================
1TISIGINFO Dump Event "systhrow" (00040000) Detail "java/lang/OutOfMemoryError" "Failed to create a thread: retVal -1073741830, errno 11" received
1TIDATETIME Date: 2012/09/13 at 16:36:01
1TIFILENAME Javacore filename: /var/lib/PostgreSQL/9.1/data/javacore.20120913.104611.24742.0002.txt
***SNIP***
Now, there are reasonably well-defined ways of ameliorating these types of problems with Java, described here:
http://www.ibm.com/developerworks/java/library/j-nativememory-linux/
I think that it would be particularly effective if I could set the maximum heap size to a value that is far lower than the default. Ordinarily, it is possible to do something along these lines:
The heap's size is controlled from the Java command line using the -Xmx and -Xms options (mx is the maximum size of the heap, ms is the initial size). Although the logical heap (the area of memory that is actively used) can grow and shrink according to the number of objects on the heap and the amount of time spent in GC, the amount of native memory used remains constant and is dictated by the -Xmx value: the maximum heap size. Most GC algorithms rely on the heap being allocated as a contiguous slab of memory, so it's impossible to allocate more native memory when the heap needs to expand. All heap memory must be reserved up front.
However, it is not apparent how I can follow these steps such that pl/java's JNI initialisation initialises a JVM with a smaller heap; I can't very well pass these command line arguments to Postgres. So, my question is, how can I set the maximum heap size or otherwise control these problems in this context specifically? This appears to be a general problem with pl/java, so I expect to be able to share whatever solution I eventually arrive at with the Postgres community.
Please note that I am not experienced with JVM internals, and am not generally familiar with Java.
Thanks

According to slide 19 in this presentation postgresql.conf can have the parameter pljava.vmoptions where you can pass arguments to the JVM.

Error while initializing Array:OutOfMemoryError

I have to allocate space to an array int input[] depending on the configuration parameters height and width.
int input[]=new int[height * width]; //this is line no 538
One of the configurations has parameters height=8192 and width=8192. So the size of the array becomes 67108864. But when i do this i get OutOfMemoryError.
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at Test.main(Test.java:538)
I have ran this program on eclipse as well as on cygwin but i am facing the same problem. I think this is not an error and not exception. How can i rectify this?

Since 8192 * 8192 * 4 = 256 M (integers are 4 bytes each), your matrix is using 256 MB of heap space by itself.
You can tell the JVM how much heap space should be available to your application. From running man java and looking through the nonstandard options:
-Xmxn
Specify the maximum size, in bytes, of the memory allocation
pool. This value must a multiple of 1024 greater than 2MB.
Append the letter k or K to indicate kilobytes, or m or M to
indicate megabytes. The default value is chosen at runtime
based on system configuration. For more information, see
HotSpot Ergonomics
Examples:
-Xmx83886080
-Xmx81920k
-Xmx80m
On Solaris 7 and Solaris 8 SPARC platforms, the upper limit for
this value is approximately 4000m minus overhead amounts. On
Solaris 2.6 and x86 platforms, the upper limit is approximately
2000m minus overhead amounts. On Linux platforms, the upper limit
is approximately 2000m minus overhead amounts.
To use this option, you would start your application with a command like
java -Xmxn1024m -jar foo.jar
In Eclipse, you can add command-line options as well. This page on eclipse.org describes how to add command-line arguments to a Java program. You should add the -Xmxn1024m (or some other sufficiently large heap specification) to the "VM arguments" section of the dialog shown on that site.

You probably have too little heap space to hold an array of the size you are targeting. You can increase the size of your heap with command line switches. For example, to set it to 256MB, include this switch:
-Xmx256m
If you multiply height * width * 4 (4 is the storage in bytes for an int) you can get a rough gauge of the amount of heap you will need, assuming the rest of the program does not need a significant amount. You will certainly need some more heap than that quick calculation suggests. Add maybe 20% extra, and try that out.
To get a better number than a rule-of-thumb calculation, you can look into heap profilers. There are several open source options:
http://java-source.net/open-source/profilers
See http://javarevisited.blogspot.com/2011/05/java-heap-space-memory-size-jvm.html for a good discussion of the heap in Java.

memory is not enough for your program, may be memory leak there.
you may try below,if not solve try to increase jmx value.
java -xmx1g -xms512m

Depends on how much heap the JVM has. If you run it on the command line try adding -Xmx512m. If you work in an IDE add it to the "Run" properties.

An int is 32 bits (i.e. 4 bytes). So your array requires 8192*8192*4 bytes. This comes out at 256MB.
Java called with default arguments has only 64MB of heap space.
To get a larger heap, call Java using the -Xmx argument (Maximum memory size).
e.g. java -Xmx300M

Increase your memory arguments for your Java process by adding this flag to increase the heap. You might need to play around to get the optimal size for the heap. This will set the "max" heap size. The default is probably really small. 64M is a common max size for many Java EE containers.
*Note I'm not saying this is exactly the size you'll need. Your unique case will dictate the size you'll need which you may need to experiment with.
-Xmx256M

Sun's JVM heap size limit on Ubuntu 64-bit

I see some strange behavior on the maximum heap size I get on Sun's JVM, compared to JRockit.
I'm running IDEA on 64-bit VMs on a 64-bit system (Ubuntu 11.04). The JVM versions I'm testing are: Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) (which I got with apt-get install sun-java6-jdk, and Oracle JRockit(R) (build R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64, compiled mode) (which I downloaded from Oracle's site a couple of months ago).
If I pass the parameters -Xms1g -Xmx3g, IDEA will report a maximum heap size of 1820M on Sun's JVM, and 3072M (as expected) on JRockit.
If I pass -Xms2g -Xmx4g, IDEA will report 3640M on Sun's and 4096M on JRockit.
What is happening? What are those mystic numbers 1820M and 3640M = 2*1820M? Isn't it possible to run Sun's JVM with the exact heap size I want?
EDIT:
An answer has been deleted, so just to bring my comments back: please note that I'm talking about the MAX size, not the current size. Consider that I've researched a lot before asking the question here, so there's no need to teach the meaning of Xms, Xmx or any of the other of the parameters that specify the size of regions of the memory (those can be found elsewhere).
EDIT2:
I wrote the following simple code to test this behavior:
public static void main(String[] args) throws Exception {
while (true) {
final Runtime r = Runtime.getRuntime();
System.out.println("r.freeMemory() = " + r.freeMemory()/1024.0/1024);
System.out.println("r.totalMemory() = " + r.totalMemory()/1024.0/1024);
System.out.println("r.maxMemory() = " + r.maxMemory()/1024.0/1024);
Thread.sleep(1000);
}
}
Then I ran it with -Xmx100m, -Xmx110m, -Xmx120m, etc... for many many different values, both on Sun's JVM and o JRockit. Sun's will always report a bizarre value for maxMemory() and would grow on big steps (like 30M) between runs. JRockit reported the exact value every time.

The Xms and Xmx only serve to indicate the minimum and maximum sizes of the allocated heap. The actual size of the allocated heap could/will be a value between the minimum and maximum, as the JVM can resize the heap, especially during object allocation events or garbage collection events.
If you need the JVM to use the "exact" heap size, you can specify Xms and Xmx values that are close enough to each other, so that heap resizing does not occur. Of course, these values must correspond to a contiguous amount of free memory.
The above section assumed something else, and can be ignored for practical purposes.
Based on the code used to calculate heap size, it should be noted that Runtime.maxMemory() returns a value that does not correspond to the value passed in the Xmx flag for the Hotspot JVM; the documentation is vague in stating that it will simply return a value that indicates the memory available for the JVM to use.
Inferring from your posted code's behavior, heap resizing will result in different values being reported for different invocations of Runtime.maxMemory(). Also, it would be needless to point out that the JRockit JVM reports the value passed in via Xmx flag.

Does an object in java have any memory size constraints?

Can we have any size of Java object without any fear of exception? I am going to use an object of a class that consists of an ArrayList of thousands of other objects that contains couples of HashMaps and ArrayLists and many other non primitive type.
Thank you

If you have an object (let's call it A) that references an ArrayList with many, many objects in it, the "size" of A will still be rather small (the size of the reference plus a bit of overhead). Objects referenced by A are pretty much independent from A. The only limit is that the total size of all objects is limited by the available memory.
The only truly "huge object" would be one with many, many fields, but there the JLS/JVM spec sets a pretty small limit (the fields_count in the class file format is an u2 field, so you can have at most 65 535 fields).

Java Heap is limit for size of objects those you can have in system. If your object's size is beyond heap then Out Of Memory error would be generated.
In your case your total object's size (Object's in ArrayList + other objects in your system) matters more, As your ArrayList would be just referencing these Object's.
Here are VM options you can use to set Heap Size as per your requirement (from the java documentation):
-Xmsn
Specify the initial size, in bytes, of
the memory allocation pool. This value
must be a multiple of 1024 greater
than 1MB. Append the letter k or K to
indicate kilobytes, or m or M to
indicate megabytes. The default value
is 2MB. Examples:
-Xms6291456
-Xms6144k
-Xms6m
-Xmxn
Specify the maximum size, in bytes, of
the memory allocation pool. This value
must a multiple of 1024 greater than
2MB. Append the letter k or K to
indicate kilobytes, or m or M to
indicate megabytes. The default value
is 64MB. Examples:
-Xmx83886080
-Xmx81920k
-Xmx80m
Check Heap info from VM Spec
3.5.3 Heap
The Java virtual machine has a heap that is shared among all Java virtual machine >threads. The heap is the runtime data area from which memory for all class instances and >arrays is allocated.
The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by >an automatic storage management system (known as a garbage collector); objects are never >explicitly deallocated. The Java virtual machine assumes no particular type of automatic >storage management system, and the storage management technique may be chosen according >to the implementor's system requirements. The heap may be of a fixed size or may be >expanded as required by the computation and may be contracted if a larger heap becomes >unnecessary. The memory for the heap does not need to be contiguous.
A Java virtual machine implementation may provide the programmer or the user control over >the initial size of the heap, as well as, if the heap can be dynamically expanded or >contracted, control over the maximum and minimum heap size.5
The following exceptional condition is associated with the heap:
If a computation requires more heap than can be made available by the automatic storage management system, the Java virtual machine throws an OutOfMemoryError.

You can't use any size object without repercussions no. You can code what you like, but obviously you need to be aware of the JVM and the typical memory / heap limits employed therein.

The only limiting factor is the maximum heap size, I also had few 100MB fat object as an in memory db.

Ofcourse it has memory limit constraints. However you can control the heap memory by initializing to a higher size. But that does not guarantee that you can use unlimited memory as you like.

The overall heap limit is the main memory constraint. As long as your objects fit within this you will fine.
You can test this if you like by allocating lots of big arrays and observing when you get OutOfMemoryErrors.
There is also an array size limit of 2147483647 due to the size of integer indexes. Never actually seen anyone run into it in practice however.

Object's memory size is based on heap memory's size.An object can hold upto heap memory's size.refer following link.http://javarevisited.blogspot.in/2011/05/java-heap-space-memory-size-jvm.html