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