I think that the memory for the ffi type is being gc'd and overwritten
sometimes.
In Structure.FFIType, if I gc
private void init(Pointer[] els) {
elements = new Memory(Pointer.SIZE * els.length);
elements.write(0, els, 0, els.length);
allocateMemory();
write();
System.gc();System.gc();System.runFinalization();
}
it always blows in dispatch init_type
I may have a patch by the time you wake up.
On Dec 14, 2007 12:10 AM, Timothy Wall <twal...@dev.java.net> wrote:
It's possible that it has something to do with nested structs. I'll
make sure I have a test for it.
I need to rework the internal FFIType init so it's not so hacky,
probably have Native.initIDs set up the proper values for the ffi
types so they can be used directly by the java side, instead of
deferring initialization until first native use. But before that
happens, I'd like to find out where the current setup is going wrong.
On Dec 13, 2007, at 6:00 PM, Duncan McGregor wrote:
OK, so the problem is that the recursive init_type call into the
nested structure is being given a bogus pointer, the typep-
elements of which are 0 or random.
This happens even when I run everything on the main Cococoa thread.
Strange, as I have a test that shows that I can pass structures of
structures by value.
I'll have a closer look in the morning.
On 13 Dec 2007, at 16:01, Timothy Wall wrote:
Since you get *both* a memory error and an invalid struct typedef,
it's possible that something is being prematurely GC'd, or not
properly set up.
Look at init_type in dispatch.c, which is where ffi typecodes are
translated to real ffi types. If the layout is done improperly it
could result in either error.
You might get some mileage by attaching gdb to the java process so
that it can catch the invalid access (recompile the native stuff
with "make DEBUG=true" or "ant -Ddebug=true" to get better source
visibility).
There's a method you can call from gdb that makes the apple VM
dump the java stack, google "apple gdb java stack dump" 'cuz I
don't remember offhand.
8 messages in net.java.dev.jna.usersRe: [jna-users] "Native call setup fa...
