[Vm-dev] A new ready-to-crash image is available

[Nicolas Cellier]

I have instrumented a bit more the fill list machinery, and here is some
logic error I caught:

  * frame #0: 0x14ad0fee Squeak3D`b3dAbort(msg="Trying to remove a face not
in fillList") at b3dMain.c:87:2 [opt]
    frame #1: 0x14ae774c Squeak3D`b3dRemoveFill(fillList=0x06852cc8,
aFace=0x068175a8) at b3dMain.c:938:54 [opt]
    frame #2: 0x14aecbe2 Squeak3D`b3dMainLoop(state=0x14b195ac,
stopReason=0) at b3dMain.c:1379:7 [opt]
    frame #3: 0x14aa5b43 Squeak3D`b3dStartRasterizer at Squeak3D.c:1701:12
[opt]

If we remove a face which is not in the list, then we are going to corrupt
the fill list...
Where does that happen?

   1376 if(leftEdge == lastIntersection) {
   1377 /* Special case if this is an intersection edge */
   1378 assert(fillList->firstFace == leftEdge->leftFace);
-> 1379 b3dRemoveFill(fillList, leftEdge->rightFace);
   1380 b3dAddFrontFill(fillList, leftEdge->rightFace);
   1381 } else {

Ah, a special case of intersection edge...
Why the rightFace would or would not be already in the fillList?
Is it really a loop invariant?
Hmm, hard to answer without deeper understanding of the whole loop...
I have not even an idea of what is left/tight/top face, so no semantic clue.

What I suggest as poor man correction is to protect the removal with a
if(b3dIsInFillList(fillList,rightFace)) condition...

Le sam. 8 févr. 2020 à 21:54, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

>
>
> Le sam. 8 févr. 2020 à 21:45, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> a écrit :
>
>>
>>
>> Le sam. 8 févr. 2020 à 01:35, Stéphane Rollandin <lecteur at zogotounga.net>
>> a écrit :
>>
>>>
>>> > Why only with fast VM? It might be yet another case of Undefined
>>> > Behavior (UB)...
>>> > I have thus recompiled the VM with UB sanitizer, and there is indeed
>>> > some UB reported:
>>> >
>>> > ../../platforms/Cross/plugins/Squeak3D/b3dMain.c:1252:29: runtime
>>> error:
>>> > left shift of negative value -760
>>> > ../../platforms/Cross/plugins/Squeak3D/b3dMain.c:1254:25: runtime
>>> error:
>>> > left shift of negative value -751
>>> > ../../platforms/Cross/plugins/Squeak3D/b3dDraw.c:317:33: runtime
>>> error:
>>> > left shift of negative value -802
>>> > ../../platforms/Cross/plugins/Squeak3D/b3dDraw.c:318:33: runtime
>>> error:
>>> > left shift of negative value -802
>>> > ../../platforms/Cross/plugins/Squeak3D/b3dDraw.c:316:33: runtime
>>> error:
>>> > left shift of negative value -114
>>> > ../../platforms/Cross/plugins/Squeak3D/b3dMain.c:829:61: runtime
>>> error:
>>> > left shift of negative value -2
>>> >
>>> > Though, the instrumented fast VM does not fail...
>>> > It might be that some aggressive optimizations assuming the absence of
>>> > UB do not occur with all the instrumentation stuff embedded...
>>>
>>> This is very dark magic.
>>>
>>> > IMO, declaring a left shift of negative int UB is sort of FOOLISH.
>>>
>>> Tell me where to vote and I'll vote for you.
>>>
>>> You cannot yet vote for opinions, except on some social networks ;)
>>
>> > We will have to protect each and every left shift in b3d with a cast...
>>>
>>> To see a good side in this, stumbling at this point upon this kind of
>>> errors must mean the 3D code in itself is quite sound. Indeed I had only
>>> a couple of similar crashes for hours of testing (well, playing).
>>>
>>> What I saw also a couple times, and which is more difficult to report,
>>> is the VM hanging at 100% CPU on its core and having to be killed
>>> externally. Could it be the same nasal demons at work?
>>>
>>> hard to say...
>> I think that you can send a SIGUSR1 to dump stacks, or attach a debugger
>> to running VM....
>>
>> Unfortunately, I also had another crash:
>>
>> ../../platforms/Cross/plugins/Squeak3D/b3dMain.c:954:43: runtime error:
>> member access within null pointer of type 'B3DPrimitiveFace' (aka 'struct
>> B3DPrimitiveFace')
>>
>> Segmentation fault Sat Feb  8 21:19:37 2020
>>
>> VM: 202002050212 nicolas at MBP-de-Nicolas
>> :Smalltalk/OpenSmalltalk/opensmalltalk-vm
>> Date: Tue Feb 4 18:12:07 2020 CommitHash: 0f974af6a
>> Plugins: 202002050212 nicolas at MBP-de-Nicolas
>> :Smalltalk/OpenSmalltalk/opensmalltalk-vm
>>
>> C stack backtrace & registers:
>> eax 0x00000018 ebx 0x00000000 ecx 0x040835a8 edx 0x00000000
>> edi 0x040835a8 esi 0x040835a8 ebp 0xbfeec978 esp 0xbfeec940
>> eip 0x0f0584b5
>> 0   Squeak3D                            0x0f0584b5 b3dAddFrontFill + 118
>> 1   Squeak                              0x00275ea4 reportStackState + 870
>> 2   Squeak                              0x00276862 sigsegv + 353
>> 3   libsystem_platform.dylib            0xa7dffbae _sigtramp + 46
>> 4   ???                                 0xffffffff 0x0 + 4294967295
>> 5   Squeak3D                            0x0f05a0ee b3dToggleTopFills + 604
>> 6   Squeak3D                            0x0f05cdc0 b3dMainLoop + 7239
>> 7   Squeak3D                            0x0f017adb b3dStartRasterizer +
>> 1668
>>
>
> And I see that this one more closely match your crash.dmp report...
> So the negativeInt<<shift was another problem created by my clang version
> on OSX.
> I ran a few times without crash, so thought it was thru, but your crash is
> not yet fixed...
>
>
>>> Stef
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200209/817c45f0/attachment.html>