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.����--On Thu, Mar 31, 2016 at 10:27 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:how does your function call looks like?The function call is:^ self ffiCall: #( GsGciOopType GciExecuteStrFromContextDbg_(String source, int64 sourceSize, GsGciOopType sourceClassOopType, GsGciOopType contextObjectOopType, GsGciOopType symbolListOopType, int flags, ushort environmentId) )And the C function SHOULD BE (I say SHOULD because I don't have access to the C source nor header):�� EXTERN_GCI_DEC(OopType)GciExecuteStrFromContextDbg_(�� const char source[], int64 sourceSize, OopType sourceClass,�� OopType contextObject, OopType symbolList,�� int flags, ��ushort environmentId );I am not sure which is the error because other times I did get an error that is was clear that it couldn't marshal the arguments. But that "bad arguments" doesn't tell me much :(On 31 Mar 2016, at 04:55, Mariano Martinez Peck <marianopeck@gmail.com> wrote:Hi guys,Could someone help me understand what could be the exact reason of a��'Bad argument for external function' in an FFI call? Of course, I double checked all the arguments definitions in the #ffiCall: and the real objects I receive as arguments at the moment of the callout. And they all seem correct.��And even better...how can I get more info about it?--