OK...I have some more info...please read the end if you have little time.
I have the same error for even a simpler function:
��GCI_ALIGN_STACK EXTERN_GCI_DEC(OopType)��
GciFetchClass(OopType theObject);
which I call this way:
apiGciFetchClass: theObject
^ self ffiCall: #( GsGciOopType GciFetchClass(GsGciOopType theObject) )
The arguments I receive at runtime (theObject) prints to something like��"GsOopType(200635137)" ��so...at least it looks like a valid object with a valid handle.��
I suspect there might be something wrong with the GsGciOopType (subclass of��FFIExternalStructure).
In the original C specification it says that OopType should be an unsigned 64-bit integer.
The way this was mapped BEFORE (with old FFI) was like this:
fields
"self compileFields"
"self byteSize"
^ #(nil 'ulonglong')
BTW... i don't understand that nil there.��
And...with the OLD FFI, GsGciOopType (originally subclass of ExternalStructure) was managed like an integer directly. For example, above GciFetchClass would directly answer the integer (the ulonglong field).
With the new approach I am doing:
fieldsDesc
^ #(
�� �� ulonglong oop;
�� )
But now... for example above GciFetchClass ��would answer an instance of GsGciOopType to which I must send #asInteger to get the integer value.
So...I suspect the same problem might be in the marshaling of the GsGciOopType instances I pass as argument. Maybe previously arrived already as integer to C while now it's different.
Any pointer is appreciated.��
��