'Bad argument for external function' with UFFI... no clue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

'Bad argument for external function' with UFFI... no clue

Mariano Martinez Peck
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?

Thanks in advance,

--
Reply | Threaded
Open this post in threaded view
|

Re: 'Bad argument for external function' with UFFI... no clue

EstebanLM
how does your function call looks like?

On 31 Mar 2016, at 04:55, Mariano Martinez Peck <[hidden email]> 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?

Thanks in advance,

--

Reply | Threaded
Open this post in threaded view
|

Re: 'Bad argument for external function' with UFFI... no clue

Mariano Martinez Peck


On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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?

Thanks in advance,

--




--
Reply | Threaded
Open this post in threaded view
|

Re: 'Bad argument for external function' with UFFI... no clue

Mariano Martinez Peck
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 <[hidden email]> wrote:


On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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?

Thanks in advance,

--




--



--
Reply | Threaded
Open this post in threaded view
|

Re: 'Bad argument for external function' with UFFI... no clue

Mariano Martinez Peck
One more addition is that the exact definition of OopType is this:

typedef uint64_t   OopType;         

On Thu, Mar 31, 2016 at 10:51 AM, Mariano Martinez Peck <[hidden email]> wrote:
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 <[hidden email]> wrote:


On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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?

Thanks in advance,

--




--



--



--
Reply | Threaded
Open this post in threaded view
|

Re: 'Bad argument for external function' with UFFI... no clue

Dale Henrichs-3
In reply to this post by Mariano Martinez Peck
Mariano,

You should be able to find the function information you need in $GEMSTONE/include/gci.hf...

Dale

On 3/31/16 6:27 AM, Mariano Martinez Peck wrote:


On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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?

Thanks in advance,

--




--

Reply | Threaded
Open this post in threaded view
|

Re: 'Bad argument for external function' with UFFI... no clue

Mariano Martinez Peck
OK, thank you guys. We chatted internally with Esteban and he proposed me a working solution :)

Best, 

On Thu, Mar 31, 2016 at 11:35 AM, Dale Henrichs <[hidden email]> wrote:
Mariano,

You should be able to find the function information you need in $GEMSTONE/include/gci.hf...

Dale


On 3/31/16 6:27 AM, Mariano Martinez Peck wrote:


On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <[hidden email][hidden email]> 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 <[hidden email]> 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?

Thanks in advance,

--




--




--