On Tue, Oct 20, 2009 at 8:06 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project