<div dir="ltr"><div>Hi Stephane,</div><div>I confirm that I can reproduce the crash with an up-to-date VM (on OSX).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 28 déc. 2019 à 19:20, Stéphane Rollandin <<a href="mailto:lecteur@zogotounga.net">lecteur@zogotounga.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Hello all,<br>
<br>
For my first post on this list, I would like to submit the bug that <br>
prevents one of my game (this one: <br>
<a href="http://www.zogotounga.net/comp/guardians.htm" rel="noreferrer" target="_blank">http://www.zogotounga.net/comp/guardians.htm</a>) to work reliably.<br>
<br>
I spent quite some time on this, and I ended up with a nice and concise <br>
way to crash the Squeak3D plugin. The image is available at:<br>
<br>
<a href="http://www.zogotounga.net/swap/crashlab3.zip" rel="noreferrer" target="_blank">http://www.zogotounga.net/swap/crashlab3.zip</a><br>
<br>
Instructions to crash the VM are detailed therein.<br>
<br>
The 3D scene is very simple, there are only three objects. The crash<br>
seems related to a race condition, because inserting a simple delay in<br>
the code prevents it - this is detailed in the image itself.<br>
<br>
I have spent days studying the Smalltalk code, and could not see<br>
anything wrong with what is sent to the plugin. It looks to my<br>
uninformed eyes as a problem of shared memory, where one rasterizing<br>
operation messes up with another happening in parallel (although no<br>
processed is being forked on the Smalltalk side).<br>
<br>
<br>
Stef<br>
</blockquote></div>