Vm-dev January 2020

vm-dev@lists.squeakfoundation.org

35 participants
236 discussions

Start a nNew thread

Build failed: opensmalltalk-vm 1.0.1901
by AppVeyor 02 Jan '20

02 Jan '20

1 0

Build failed: opensmalltalk-vm 1.0.12
by AppVeyor 02 Jan '20

02 Jan '20

1 0

VM crash in the Squeak3D plugin
by Stéphane Rollandin 01 Jan '20

01 Jan '20

Hello all, For my first post on this list, I would like to submit the bug that prevents one of my game (this one: http://www.zogotounga.net/comp/guardians.htm) to work reliably. I spent quite some time on this, and I ended up with a nice and concise way to crash the Squeak3D plugin. The image is available at: http://www.zogotounga.net/swap/crashlab3.zip Instructions to crash the VM are detailed therein. The 3D scene is very simple, there are only three objects. The crash seems related to a race condition, because inserting a simple delay in the code prevents it - this is detailed in the image itself. I have spent days studying the Smalltalk code, and could not see anything wrong with what is sent to the plugin. It looks to my uninformed eyes as a problem of shared memory, where one rasterizing operation messes up with another happening in parallel (although no processed is being forked on the Smalltalk side). Stef

4 17

[OpenSmalltalk/opensmalltalk-vm] Fix to Squeak3D b3dMain.c::b3dMailLoop is only a partial fix (#463)
by Eliot Miranda 01 Jan '20

01 Jan '20

(Line numbers correct at time of writing) There is a major loop in b3dMainLoop with condition `while(aetStart < aetSize) {` at line 1352 which is in the MAIN LOOP at 1227. At line 1372 there is a sub loop with condition `else while(aetStart < aetSize) {` which ends with the code ``` /* If the edge is not on top toggle its (back) fills */ b3dToggleBackFills(fillList, rightEdge, yValue, nextIntersection); rightEdge = NULL; } /*-- end of search for next top edge --*/ ``` This code used to create crashes because following the if-then-else containing the loop in the else branch there was nothing to handle a NULL rightEdge. I extended the assert that was there from `assert(leftEdge);` to `assert(leftEdge && rightEdge);` and that allowed us to identify the assignment as the cause of crashes in games written by @Stéphane Rollandin. Recently Stéphane encouraged me to take another look at the code and I was able to create a patch that stopped the plugin from crashing. That added the following to the code to break out of the main loop ``` /* If the edge is not on top toggle its (back) fills */ b3dToggleBackFills(fillList, rightEdge, yValue, nextIntersection); rightEdge = NULL; } /*-- end of search for next top edge --*/ /* If the "edge is not on top toggle its (back) fills" guard * above nilled rightEdge then presumably we're done. So * arrange that we quit the main loop (see BEGIN MAINLOOP at * about line 1227 above). eem 2019/12/29 */ if (!rightEdge) { aet->size = 0; b3dCleanupFill(fillList); break; } assert(leftEdge && rightEdge); /*-- Now do the drawing from leftEdge to rightEdge --*/ if(fillList->firstFace) { ... ``` Stéphane does confirm that this fixes the crash but it is not a good fix; he experiences glitches: ``` I have now played a fair bit with my game and I have not had any crash so far. But, instead, there are rendering glitches at times. Of course I suppose that these glitches occurs whenever the plugin would have crashed previously. It's no big deal, but it shows that indeed, as you stated, some continuation is needed when "the edge is not on top" to "toggle its (back) fills", whatever that means. Best, Stef ``` So the challenge is to determine what should happen at this point. There are several failure macros which resume in various ways, see lines 1558 forward: ``` /* Failure adding objects */ #define FAIL_ADDING(reason) { obj->start = objStart; FAIL(reason, B3D_RESUME_ADDING) } #define PROCEED_ADDING { objStart = obj->start; PROCEED } /* Failure merging objects */ #define FAIL_MERGING(reason) { FAIL(reason, B3D_RESUME_MERGING); } #define PROCEED_MERGING { PROCEED } /* Failure during paint */ #define FAIL_PAINTING(reason) { aet->start = aetStart; aet->leftEdge = leftEdge; aet->rightEdge = rightEdge; FAIL(reason, B3D_RESUME_PAINTING) } #define PROCEED_PAINTING(reason) { aetStart = aet->start; leftEdge = aet->leftEdge; rightEdge = aet->rightEdge; PROCEED } ``` So what kind of failure is described by Andreas' comment "If the edge is not on top toggle its (back) fills"? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/463

1 0

that she blows!
by gettimothy 01 Jan '20

01 Jan '20

Beautiful simulator. Very impressive stuff. Congrats!

1 0

The VM to tag
by Eliot Miranda 01 Jan '20

01 Jan '20

Hi All, so it seems things are stabilizing. The CI builds. The recent commits from Nicolas re events seem like goodness to me. Are we agreed that I should tag the a4a08f98c17b23ad54b5e361ffc0280e2ea8e0c3 commit or does anyone suggest an earlier one? This commit has VM sources that are unchanged since Pablo Tesone's fix for gcc compilation of immediate floats. It includes the socket name lookup fixes Levente wanted, and it has very localized but useful fixes for events. My vote would be to choose this. _,,,^..^,,,_ best, Eliot

4 16

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev January 2020