Hi Guille,<div><br></div><div> 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.</div>
<div><br></div><div>There are two solutions to this.</div><div>One would be to reuse the compactClassesArray (my recommendation). So that recreateSpecialObjectsArray looks like</div><div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>...</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span>"An array of the 255 Characters in ascii order.</div><div><span class="Apple-tab-span" style="white-space:pre">        </span> Cog inlines table into machine code at: prim so do not regenerate it."</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span>newArray at: 25 put: Character characterTable.</div></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>...</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>"A 32-element array with up to 32 classes that have compact instances.</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span> Cog inlines table into machine code class lookup so do not regenerate it."</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>newArray at: 29 put: self compactClassesArray.</div>
<span class="Apple-tab-span" style="white-space:pre">        </span>...<div><br><div>where compactClassesArray, like Character characterTable, answers the existing object.</div><div><br></div><div>The second solution (rather hackish) is to void all machine code on installing the new specialObjectsArray. e.g.</div>
<div><div>recreateSpecialObjectsArray</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>"Smalltalk recreateSpecialObjectsArray"</div><div><span class="Apple-tab-span" style="white-space:pre">        </span></div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span>"To external package developers:</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>**** DO NOT OVERRIDE THIS METHOD. *****</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span>If you are writing a plugin and need additional special object(s) for your own use, </div><div><span class="Apple-tab-span" style="white-space:pre">        </span>use addGCRoot() function and use own, separate special objects registry "</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>"The Special Objects Array is an array of objects used by the Squeak virtual machine.</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span> Its contents are critical and accesses to it by the VM are unchecked, so don't even</div><div><span class="Apple-tab-span" style="white-space:pre">        </span> think of playing here unless you know what you are doing."</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>"Replace the interpreter's reference in one atomic operation.</div><div><span class="Apple-tab-span" style="white-space:pre">        </span> Void machine code to avoid crashing Cog."</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span>| newSpecialObjectsArray |</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>newSpecialObjectsArray := self newSpecialObjectsArray.</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span>self specialObjectsArray becomeForward: newSpecialObjectsArray.</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Smalltalk vm voidCogVMState</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>HTH,</div><div>Eliot<br><br><div class="gmail_quote">On Sat, Mar 23, 2013 at 10:19 AM, Guillermo Polito <span dir="ltr"><<a href="mailto:guillermopolito@gmail.com" target="_blank">guillermopolito@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<div><br></div><div>In my quest to crash the vm, i've found an ugly common case :(.<div>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).</div>
<div><br></div><div>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.</div><div>The snippet of code that gets a sistematic crash is:</div><div><br></div>
<div><div>Gofer it</div><div><span style="white-space:pre-wrap">        </span>smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver';</div><div><span style="white-space:pre-wrap">        </span>package: 'ConfigurationOfOpenDBXDriver';</div>
<div><span style="white-space:pre-wrap">        </span>load.</div><div><span style="white-space:pre-wrap">        </span></div><div>((Smalltalk at: #ConfigurationOfOpenDBXDriver) project version:#stable) load</div>
</div><div><br></div><div><br></div><div>This snippet crashes always with a segmentation fault (at least the fifteen times i tried :), with several different output in the console...</div><div><br></div><div>Surprisingly, if I load FFI alone and not from the OpenDBXDriver configuration, it loads well... :/</div>
<div><br></div><div>So I'm deferring the OpenDBX port a bit longer :(</div><div><br></div><div>Thanks!</div><div>Guille</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div></div>