Ok, as a summary. I've tried<div><br></div><div>1) not recreating the compact classes array without voiding vm caches: works ok.</div><div><br></div><div>2) making another compact classes array, voiding the vm caches (primitive 214): random crashes :/. Sometimes it works, some times it does not...</div>
<div>I've tried, just for the record, to void the cache before, after and (before and after) the become forward of the special objects array:</div><div><br></div><div>a)</div><div>| newSpecialObjectsArray |</div><div>
self vm voidCogVMState.</div><div>newSpecialObjectsArray := self newSpecialObjectsArray.</div><div>self specialObjectsArray becomeForward: newSpecialObjectsArray.<br><div><br></div><div><div>b)</div><div>| newSpecialObjectsArray |</div>
<div>newSpecialObjectsArray := self newSpecialObjectsArray.</div><div>self specialObjectsArray becomeForward: newSpecialObjectsArray.</div></div><div>self vm voidCogVMState.</div><div><br></div><div><div>c)</div><div>| newSpecialObjectsArray |</div>
<div>self vm voidCogVMState.</div><div>newSpecialObjectsArray := self newSpecialObjectsArray.</div><div>self specialObjectsArray becomeForward: newSpecialObjectsArray.</div></div><div>self vm voidCogVMState.</div><div><br>
</div><div>All with different results when executing several times... :/</div><div><br></div><div>voidCogVMState is the following in Pharo:</div><div><br></div><div>VirtualMachine class>>voidCogVMState</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"Void any internal caches the VM maintains other than the method lookup caches.</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> These comprise</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- the stack zone, where method activations are stored, and</div><div>
<span class="Apple-tab-span" style="white-space:pre"> </span>- the machine code zone, where the machine code form of CompiledMethods is held."</div><div><span class="Apple-tab-span" style="white-space:pre"> </span><primitive: 214></div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>^self primitiveFailed</div><div><br></div><div>The comment says it does not clean method lookup caches...</div><div><br></div><div>any ideas?</div><div>Guille</div>
<div><br></div><div><div class="gmail_quote">On Tue, Mar 26, 2013 at 11:48 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">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...<div>
Second, thanks for taking the time to look at it :).</div><div><br></div><div>Now, I've some questions:</div>
<div><br></div><div>- 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?</div><div>- 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...</div>
<div><br></div><div>Tx!</div><div>Guille</div><div><br><div class="gmail_quote">On Mon, Mar 25, 2013 at 11:56 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@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><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 class="im"><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><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><div class="h5">
<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><div><br>
<br>
On 2013-03-25, at 19:52, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">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" target="_blank">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></div></div><br><br clear="all"><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br>best,<div>Eliot</div>
<br></font></span></blockquote></div><br></div>
</blockquote></div><br></div></div>