[Vm-dev] Re: Reproducible VM crash when loading FFI

[Camillo Bruni]

Thanks for the findings!

I opened an issue http://bugs.pharo.org/issues/id/10134 with the contents
of your solution.

I think for completeness we should implement both solution, and of course
use the one that does not #becomeForward: in the standard case.


On 2013-03-25, at 19:52, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Guille,
> 
>    thanks for this.  The problem is that Pharo's
> recreateSpecialObjectsArray uses newCompactClassesArray to recreate the
> compact classes array and on Cog that is not supported.  Cog caches the
> compactClassesArray (specialObjectsArray at: 29) in every jitted method
> prolog to reduce the time taken to derive the receiver's class in message
> lookup.  The Pharo 2.0 code for recreating the specialObjectsArray can
> therefore create a dangling pointer where the only reference to the old
> compactClassesArray is in machine code, and the machine code GC doesn't
> cope with there being roots in machine code.  Note that Cog also caches the
> characterTable and class SmallInteger in machine code.
> 
> There are two solutions to this.
> One would be to reuse the compactClassesArray (my recommendation).  So that
> recreateSpecialObjectsArray looks like
> 
> ...
> "An array of the 255 Characters in ascii order.
> Cog inlines table into machine code at: prim so do not regenerate it."
> newArray at: 25 put: Character characterTable.
> ...
> "A 32-element array with up to 32 classes that have compact instances.
> Cog inlines table into machine code class lookup so do not regenerate it."
> newArray at: 29 put: self compactClassesArray.
> ...
> 
> where compactClassesArray, like Character characterTable, answers the
> existing object.
> 
> The second solution (rather hackish) is to void all machine code on
> installing the new specialObjectsArray.  e.g.
> recreateSpecialObjectsArray
> "Smalltalk recreateSpecialObjectsArray"
> "To external package developers:
> **** DO NOT OVERRIDE THIS METHOD.  *****
> If you are writing a plugin and need additional special object(s) for your
> own use,
> use addGCRoot() function and use own, separate special objects registry "
> "The Special Objects Array is an array of objects used by the Squeak
> virtual machine.
> Its contents are critical and accesses to it by the VM are unchecked, so
> don't even
> think of playing here unless you know what you are doing."
> "Replace the interpreter's reference in one atomic operation.
> Void machine code to avoid crashing Cog."
> | newSpecialObjectsArray |
> newSpecialObjectsArray := self newSpecialObjectsArray.
> self specialObjectsArray becomeForward: newSpecialObjectsArray.
> Smalltalk vm voidCogVMState
> 
> 
> this is my fault for not ensuring recreateSpecialObjectsArray was properly
> commented.  I had commented the inlining of Character table, but not the
> inlining of the CompactClasses array. Apologies.
> 
> HTH,
> Eliot
> 
> On Sat, Mar 23, 2013 at 10:19 AM, Guillermo Polito <
> guillermopolito at gmail.com> wrote:
> 
>> Hi!
>> 
>> In my quest to crash the vm, i've found an ugly common case :(.
>> I am trying to port the opendbx driver to 2.0, but I'm getting vm crashes
>> when my configuration loads FFI :(. I updated my configuration to load
>> version 1.7 of FFI (which I assume is the latest).
>> 
>> I tried to do it in Pharo 2.0 with latest pharovm, and with eliot's Cog
>> 2701 from his website, failing in both cases.
>> The snippet of code that gets a sistematic crash is:
>> 
>> Gofer it
>> smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver';
>> package: 'ConfigurationOfOpenDBXDriver';
>> load.
>> ((Smalltalk at: #ConfigurationOfOpenDBXDriver) project version:#stable)
>> load
>> 
>> 
>> This snippet crashes always with a segmentation fault (at least the
>> fifteen times i tried :), with several different output in the console...
>> 
>> Surprisingly, if I load FFI alone and not from the OpenDBXDriver
>> configuration, it loads well... :/
>> 
>> So I'm deferring the OpenDBX port a bit longer :(
>> 
>> Thanks!
>> Guille
>> 
> 
> 
> 
> -- 
> best,
> Eliot