[Pharo-project] Odd FFI problms with Mac vms...
eliot.miranda at gmail.com
Mon Apr 4 04:38:32 CEST 2011
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
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 184.108.40.206 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..
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project