Invalid Memory Access problem and Structure.toString taking forever

[Will S]

Hi!
I'm trying to access on a library called libraw but I'm stuck with
Illegal Memory Access errors at the first method call.

The function is defined as
DllDef int libraw_open_file(libraw_data_t*, const
char *);

and my definition is:
int libraw_open_file(libraw_data_t librawData, String fileName);

I have generated the libraw_data_t structure and all its nested
structures from the .h file using JNAeretor. I have bundled the DLL,
the .h file and a small sample Java app in a zip that I've put up here
http://saar.se/temp/example.zip , maybe someone has time to take a
quick look for obvious problems?

I read about a debugging tip with the toString method, but that method
is taking forever to execute on the main structure and dumps a lot of
info, is it supposed to be that slow?

Thanks!
William

[Timothy Wall]

By "forever to execute" do you mean the call hangs, or do you mean it takes greater than X amount of time?

Most likely you've made an error in defining the CPP macros that JNAerator must use in order to parse your header.

Compare the native size of structure X with its Java equivalent. That will likely help you narrow down the issue.

If you *do* find a bug in Structure.toString, please don't hesitate to file an issue for it (with an associated test case, of course).

[Will S]

Ok, thanks. I took a step back and tried printing a simple structure
with just two float values with the result below. The memory dump
seems to indicate 64-bit floats in native memory rather than 32-bit
floats mentioned in the toString-printout (and shouldn't the memory
dump be populated with some values?).

Can JNA handle that I'm calling a 32-bit library from a 32-bit JVM om
a 64-bit Win7 ?

LibrawBindingPlugin$TestStruct(allocated@0x761560 (8 bytes)) {
float value1@0=23.4
float value2@4=8.0
}
memory dump
[00000000]
[00000000]

[Timothy Wall]

The dump you provide indicates 32-bit (4-byte) floats. the @NN indicates the field offset.

The memory dump will be all zeroes for newly-created structures (the memory is cleared).

The VM is ignorant of the fact that it's running on a 64-bit OS, as is JNA.

[Will S]

Ok, but why does the memory dump below the text output show 16 bytes
(two rows of 8 zeroes) if the structure is truly made up of 8 bytes?

I followed the advice in your initial post and tried to find whatever
dependencies that JNAerator may be lacking so I downloaded Microsoft
Visual Studio and SDK and set the appropriate paths in JNAerator's
config. However, then JNAerator stopped complaining about missing
stdio.h, memory.h etc. but only generated 1 Library class with a few
constants and no structures or anything. When I set the WINDOWS_SDK
and VISUAL_STUDIO paths to erronous values, JNAerator complains that i
can't find those standard libraries but at least generates full
structures (except for a structure based on time_t in the sys/
time.h).

Anyway, so far I have at least learnt that Visual Studio Express is
available for free, which means I can give JNI a shot as well.

[Timothy Wall]

On May 17, 2012, at 11:22 AM, Will S wrote:

> Ok, but why does the memory dump below the text output show 16 bytes
> (two rows of 8 zeroes) if the structure is truly made up of 8 bytes?

one byte is represented by two ascii characters.

[Will S]

Thanks for your patience, been a decade since I had to look at hex
dump :)