[Pharo-project] Odd FFI problms with Mac vms...

Eliot Miranda eliot.miranda at gmail.com
Mon Apr 4 04:38:32 CEST 2011


Hi Dale,

    this is a known issue spotted and fixed by Ken Treis.  I've been tardy
in integrating the fix.  I'll try and do that in the next couple of days.  A
test case would help (Ken, Dale?).

If you want to try Ken's fix in advance then see
http://lists.gforge.inria.fr/pipermail/pharo-project/2011-March/044521.html

Apologies,
Eliot

On Sun, Apr 3, 2011 at 1:04 PM, Dale Henrichs <dhenrich at vmware.com> wrote:

>
> On Apr 3, 2011, at 12:48 PM, Dale Henrichs wrote:
>
> >
> > On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote:
> >
> >> Norbert,
> >>
> >> Today I have found that I can get GemTools to work on the mac using
> Squeak 4.2.4beta1U.
> >>
> >> Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value
> (get a Space is low error, because the size comes back as
> 1330942246849085449, instead of a reasonable number).
> >>
> >> The image is identical and the gci library file is identical in both
> cases, I've just switched the vm that I'm using.
> >>
> >> Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first
> FFI call into the library.
> >>
> >> Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call
> that returns the unreasonable number in 4.2.5beta1U...the argument to the
> function is a SmallInteger (343552513) ... at least this error gives me hope
> that I can figure out what's wrong with this call sooner or later ...
> >>
> >> Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the
> moment on the Mac for running GemTools ...
> >>
> >> Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works
> gives me an incentive to try getting GemTools running on PharoCore.1.2...
> >>
> >> If any of the vm or FFI guys have some insight to these problems I'd
> appreciate some pointers to what may be going on...
> >
> > Here's the FFI call:
> >
> >  apiGciFetchObjImpl: anOopType
> >
> >       <apicall: ulong 'GciFetchObjImpl' (OopType64) >
> >       ^self externalCallFailed
> >
> > and OopType64 is a subclass of ExternalStructure with the following
> fields declaration:
> >
> >  fields
> > "
> >       (OopType64 defineFields)
> > "
> >
> >       ^#(asOop 'ulonglong').
> >
> > and the function declaration from the header file:
> >
> >  int GciFetchObjImpl(OopType theObject);
>
> I thought it might be suspicious that a SmallInteger was being passed in
> when the argument type should have been OopType, so in the Cog vm, I traced
> the source of the argument back to the _result_ another FFI call:
>
>        <apicall: OopType64 'GciNbPerform' (OopType64 char* ulong long) >
>
> The result is declared as OopType64 so it looks like the result was not
> converted to the correct type on return...which ends up with the incorrect
> argument coming in ..
>
> When the Squeak 4.2.5beta1U runs through the same sequence of calls, the
>  result of GciNbPerform gets correctly converted to OopType64, so that seems
> to be the ulitmate source of the error ...
>
> Not sure whether this is a VM issue or an FFI issue, in either case I
> assume that the bug exists in some C code floating around somewhere..
>
> Dale
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110403/37609dd2/attachment.htm>


More information about the Pharo-project mailing list