OK, so
private Pointer getTypeInfo() {
synchronized(typeInfoMap) {
Pointer info = (Pointer)typeInfoMap.get(getClass());
if (info == null) {
FFIType type = new FFIType(this);
info = type.getPointer();
typeInfoMap.put(getClass(), info);
}
return info;
}
}
puts only the pointer into the map, but the pointer is to memory allocated
by the FFIType, which is freed when it is gc'd. Putting the FFIType into the
map (not so bad as it's a weak map) solves my problems.
private Pointer getTypeInfo() {
synchronized(typeInfoMap) {
FFIType info = (FFIType) typeInfoMap.get(getClass());
if (info == null) {
info = new FFIType(this);
typeInfoMap.put(getClass(), info);
}
return info.getPointer();
}
}
Somehow, days spent debugging this sort of stuff are the happy ones ;-)
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.
8 messages in net.java.dev.jna.usersRe: [jna-users] "Native call setup fa...
