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

Tue Mar 26 16:48:25 UTC 2013

On Tue, Mar 26, 2013 at 3:48 AM, Guillermo Polito <guillermopolito at gmail.com
> wrote:

>
> Ok, first I'm sorry for the evil upload. That was the first at hand
> :$. I'll get a more trustful way to do it the next one...
> Second, thanks for taking the time to look at it :).
>
> Now, I've some questions:
>
> - this "bug" is particular to Cog, isn't it? I mean, only related to
> inlining with JIT, so a Stack vm does not play with these rules, right?
>

Right.

> - Why is voiding the cache hackish? I mean, replacing the special objects
> array is a very low level operation, and a very special one which is not
> commonly performed. Voiding the cache looks like normal to me in such a
> case...
>

Because it's specific to Cog.  Whereas the reusing of existing contents
will work on all VMs.

>
> Tx!
> Guille
>
> On Mon, Mar 25, 2013 at 11:56 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>>
>>
>> On Mon, Mar 25, 2013 at 3:22 PM, Camillo Bruni <camillobruni at gmail.com>wrote:
>>
>>>
>>> Thanks for the findings!
>>>
>>
>> you're welcome :)
>>
>>
>>>
>>> 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.
>>>
>>
>> To be clear, becomeForward: is the correct way to install the
>> specialObjectsArray.  The issue is what entries in the specialObjectsArray
>> need to remain constant.  The Character table, the compactClassesArray, all
>> the classes and a few other entries (semaphores, etc) must remain the same.
>>  This could do with better documenting of the method :-/
>>
>>
>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130326/9989c44a/attachment-0001.htm