[Vm-dev] VM crash in the Squeak3D plugin
Eliot Miranda
eliot.miranda at gmail.com
Sun Dec 29 18:09:02 UTC 2019
Hi Nicolas,
On Sun, Dec 29, 2019 at 10:01 AM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:
>
> Thanks to Stephane, we have a reproducible case and might understand
> why/how this happens...
> Unfortunately, I have no idea what the algorithm does, it would deserve
> some more documentation.
> Is this a classical algorithm that can be found in litterature?
>
I'm with you. As I understand it this is a standard "break things into
triangles and then render the scan lines along the edges of the triangles"
3D graphics algorithm, but at that point my "expertise" is revealed to be
as vacuous as it is. I think its straight-forward to fix for someone who
understands the algorithm. If "the edge is not on top toggle its (back)
fills" the algorithm is nilling rightEdge (presumably to abort rendering
that triangle?), and presumably this happens very rarely, rarely enough
that Andreas never noticed he hadn't;'t programmed in the right
continuation. SO the question for people who can understand the algorithm
is what the correct continuation is.
BTW, we're talking about the b3dMainLoop routine
in platforms/Cross/plugins/Squeak3D/b3dMain.c
Another question is did Andreas ever prototype this in Smalltalk or did he
write the C directly? (I suspect the latter). On the off chance that he
did prototype it, and one have any inkling where the Smalltalk code exists?
>
> Le dim. 29 déc. 2019 à 18:50, Eliot Miranda <eliot.miranda at gmail.com> a
> écrit :
>
>>
>> Hi Nicolas, Hi Stéphane,
>>
>> On Sat, Dec 28, 2019 at 2:24 PM Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>>
>>> I forgot to say that I had an assert failure report:
>>>
>>> leftEdge && rightEdge 1398
>>>
>>> Looking around line 1398:
>>>
>>> /*-- search for the next top
>>> edge which will be the right edge --*/
>>> assert(aetStart < aetSize);
>>> if(!fillList->firstFace)
>>> rightEdge =
>>> aetData[aetStart++]; /* If no current top fill just use the next edge */
>>> else while(aetStart < aetSize) {
>>> /* Search for the next top edge in the AET */
>>> rightEdge =
>>> aetData[aetStart];
>>> /* If we have an
>>> intersection use the intersection edge */
>>>
>>> if(nextIntersection->xValue <= rightEdge->xValue) {
>>> rightEdge =
>>> nextIntersection;
>>> break;
>>> }
>>> aetStart++;
>>> /* Check if this edge is
>>> on top */
>>>
>>> assert(fillList->firstFace);
>>> {
>>> double xValue =
>>> rightEdge->xValue * B3D_FixedToFloat;
>>> B3DPrimitiveFace
>>> *topFace = fillList->firstFace;
>>> if(
>>> rightEdge->leftFace == topFace ||
>>>
>>> rightEdge->rightFace == topFace ||
>>>
>>> rightEdge->zValue < zValueAt(topFace, xValue, yValue))
>>> break;
>>> /* rightEdge is on top */
>>> }
>>> /* 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 --*/
>>>
>>> /*-- Now do the drawing from
>>> leftEdge to rightEdge --*/
>>> #if 1 /* This assert fails in rare cases; the fix is not understood. eem
>>> */
>>> assert(leftEdge && rightEdge);
>>> #else
>>> if(!leftEdge || !rightEdge)
>>>
>>> FAIL_UPDATING(B3D_NO_MORE_EDGES); // another segfault
>>>
>>> //FAIL_PAINTING(B3D_NO_MORE_EDGES); // blow up in allocating edges
>>> #endif
>>> if(fillList->firstFace) {
>>> /* Note: We fill
>>> *including* leftX and rightX */
>>> int leftX =
>>> (leftEdge->xValue >> B3D_FixedToIntShift) + 1;
>>> int rightX =
>>> (rightEdge->xValue >> B3D_FixedToIntShift);
>>>
>>> So I'm pretty sure that we went thru:
>>>
>>> /* If the edge is not on
>>> top toggle its (back) fills */
>>>
>>> b3dToggleBackFills(fillList, rightEdge, yValue, nextIntersection);
>>> rightEdge = NULL;
>>>
>>> if intention of #if 1... assert(...) was probably to debug the case of
>>> failure...
>>> But it was left in the release. Maybe it would be safer to replace with
>>> #ifdef DEBUG or something like that?
>>> Eliot?
>>>
>>
>> I remember now.
>>
>> The original code read
>>
>> - assert(rightEdge);
>>
>> and this din't catch the crash. So I added the #else arm:
>>
>> + if(!leftEdge || !rightEdge)
>> +
>> FAIL_PAINTING(B3D_NO_MORE_EDGES); // blow up in allocating edges
>>
>> which caused the system to fail not being able to allocate edges. So I
>> tried an alternative:
>>
>> + if(!leftEdge || !rightEdge)
>> +
>> FAIL_UPDATING(B3D_NO_MORE_EDGES); // another segfault
>>
>> which caused segfaults. So I added the stronger assert, and ifdefed out
>> my two attempts at failing correctly in the #else arm.
>>
>> + assert(leftEdge && rightEdge);
>>
>> So by all means strip the code back to the assert, but I think that the
>> information that both of those attempts at remediation,
>> FAIL_PAINTING(B3D_NO_MORE_EDGES); and FAIL_UPDATING(B3D_NO_MORE_EDGES);,
>> failed and for different reasons might be useful to know.
>>
>> The question is under what circumstances does the assert(leftEdge &&
>> rightEdge); fail?
>>
>>>
>>> Le sam. 28 déc. 2019 à 23:04, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>>
>>>> Running SqueakDebug.app in lldb, I get:
>>>>
>>>> Process 61332 stopped
>>>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>>>> EXC_BAD_ACCESS (code=1, address=0x18)
>>>> frame #0: 0x09f17c07 Squeak3D`b3dMainLoop(state=0x09f1928c,
>>>> stopReason=0) at b3dMain.c:1407:32
>>>> 1404 if(fillList->firstFace) {
>>>> 1405 /* Note: We fill *including* leftX and rightX */
>>>> 1406 int leftX = (leftEdge->xValue >> B3D_FixedToIntShift) + 1;
>>>> -> 1407 int rightX = (rightEdge->xValue >> B3D_FixedToIntShift);
>>>> 1408 B3DPrimitiveFace *topFace = fillList->firstFace;
>>>> 1409
>>>> 1410 if(leftX < 0) leftX = 0;
>>>> Target 0: (Squeak) stopped.
>>>> (lldb) print rightEdge
>>>> (B3DPrimitiveEdge *) $0 = 0x00000000
>>>> (lldb) print leftEdge
>>>> (B3DPrimitiveEdge *) $1 = 0x0617a49c
>>>> (lldb) bt
>>>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>>>> EXC_BAD_ACCESS (code=1, address=0x18)
>>>> * frame #0: 0x09f17c07 Squeak3D`b3dMainLoop(state=0x09f1928c,
>>>> stopReason=0) at b3dMain.c:1407:32
>>>> frame #1: 0x09f0cb23 Squeak3D`b3dStartRasterizer at
>>>> Squeak3D.c:1704:12
>>>> frame #2: 0x05d01398
>>>> frame #3: 0x00002f52 Squeak`interpret at gcc3x-cointerp.c:2749:3
>>>>
>>>> So why rightEdge is a null pointer?
>>>> If you already examined the code, you may have an idea...
>>>>
>>>> Le sam. 28 déc. 2019 à 22:55, Nicolas Cellier <
>>>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>>>
>>>>> Hi Stephane,
>>>>> I confirm that I can reproduce the crash with an up-to-date VM (on
>>>>> OSX).
>>>>>
>>>>> Le sam. 28 déc. 2019 à 19:20, Stéphane Rollandin <
>>>>> lecteur at zogotounga.net> a écrit :
>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>
--
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191229/1f7484c8/attachment-0001.html>
More information about the Vm-dev
mailing list