On Tue, Oct 20, 2009 at 8:06 AM, Henrik Johansen <
[email protected]> wrote:
> This one is caused by an initialization bug of some sort, the
> byteSizes of ODBC-structs are incorrect.
>
> In short, the solution is to do:
> ExternalStructure allSubclassesDo: [:each | each compileFields]
> after you load a package which defines ExternalStructure subclasses
> (like ODBC does).
>
>
Hi Henrik! Nice to see you arround ;)
In SqueakDBX I use FFI, I have subclasses of ExternalStructure and I don't
remember having to do that. The only thing I do in those subclasses is to
implement a class side method initialize like this:
initialize
super initialize.
self defineFields
And then, if you see defineFields you will se that at the end, it does a
compileField...
You can see defineFields in FFI documentation:
http://wiki.squeak.org/squeak/2426
So, in my opinion a better solution may be this. What do you think ?
Cheers
Mariano
> For some reason, in an image after loading:
>
> ExternalStrucure >> byteSize
> "Return the size in bytes of this structure."
> ^self compiledSpec first bitAnd: FFIStructSizeMask
>
> SQLHENV compiledSpec first: 65536
> FFIStructSizeMask: 65535...
>
> So basically, when you allocate the struct a handle of a ByteArray of
> size byteSize, you'll sooner or later you access unallocated memory
> and crash.
> Recomputing all the compiledSpecs with the doit above leads to the
> correct sizes (4 in the case of SQLHENV) being stored in the
> compiledSpecs.
>
> Either way, not raising an error when the size for a struct when
> and'ed with the mask, but instead causing a silent crash later on
> just seems bad bad bad to me.
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
