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

Mariano Martinez Peck marianopeck at gmail.com
Mon Apr 4 09:45:15 CEST 2011


I've added http://code.google.com/p/cog/issues/detail?id=23

On Mon, Apr 4, 2011 at 4:38 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> 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
>>
>>
>>
>


-- 
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110404/e45a3f22/attachment.htm>


More information about the Pharo-project mailing list