<div dir="ltr"><div>So it seems that this second failure related to wrong B3D_FACE_ACTIVE was caused by my own fix.</div><div>The bug should have disappeared after <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/36a1f1e2ef637347ed3b81a2f4cf8df347e4d803">https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/36a1f1e2ef637347ed3b81a2f4cf8df347e4d803</a></div><div><br></div><div>Without a proper understanding, this must be considered as a "workaround" rather than a proper fix.</div><div>It means that it solves the symptoms, but maybe not the root cause...</div><div>I consider that it's nice to have a Squeak3D plugin working.</div><div>But remember that it's using CPU rather than GPU, so it should presumably be superseded by something more to date.</div><div>If only we could properly document the algorithm, that would also avoid wild guesses, workarounds and incomplete patches...<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 9 févr. 2020 à 12:38, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</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"><div dir="ltr"><div>With instrumentation, I see another instance of removal of absent face from the fill list in b3dToggleTopFills</div><div>The logic here seems to be that we expect B3D_FACE_ACTIVE flagged face to be on fill list, and we toggle both.</div><div>So there is another broken invariant.</div><div><br></div><div>The poor man correction is just a correction of symptoms, not of root cause.</div><div>I'd prefer the later if ever we can...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 9 févr. 2020 à 11:20, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</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"><div dir="ltr"><div>I have instrumented a bit more the fill list machinery, and here is some logic error I caught:</div><div><br></div><div> * frame #0: 0x14ad0fee Squeak3D`b3dAbort(msg="Trying to remove a face not in fillList") at b3dMain.c:87:2 [opt]<br> frame #1: 0x14ae774c Squeak3D`b3dRemoveFill(fillList=0x06852cc8, aFace=0x068175a8) at b3dMain.c:938:54 [opt]<br> frame #2: 0x14aecbe2 Squeak3D`b3dMainLoop(state=0x14b195ac, stopReason=0) at b3dMain.c:1379:7 [opt]<br> frame #3: 0x14aa5b43 Squeak3D`b3dStartRasterizer at Squeak3D.c:1701:12 [opt]</div><div><br></div><div>If we remove a face which is not in the list, then we are going to corrupt the fill list...</div><div>Where does that happen?</div><div><br></div><div> 1376 if(leftEdge == lastIntersection) {<br> 1377 /* Special case if this is an intersection edge */<br> 1378 assert(fillList->firstFace == leftEdge->leftFace);<br>-> 1379 b3dRemoveFill(fillList, leftEdge->rightFace);<br> 1380 b3dAddFrontFill(fillList, leftEdge->rightFace);<br> 1381 } else {</div><div><br></div><div>Ah, a special case of intersection edge...</div><div>Why the rightFace would or would not be already in the fillList?</div><div>Is it really a loop invariant?<br></div><div>Hmm, hard to answer without deeper understanding of the whole loop...</div><div>I have not even an idea of what is left/tight/top face, so no semantic clue.</div><div><br></div><div>What I suggest as poor man correction is to protect the removal with a if(b3dIsInFillList(fillList,rightFace)) condition...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 8 févr. 2020 à 21:54, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 8 févr. 2020 à 21:45, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 8 févr. 2020 à 01:35, Stéphane Rollandin <<a href="mailto:lecteur@zogotounga.net" target="_blank">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>
> Why only with fast VM? It might be yet another case of Undefined <br>
> Behavior (UB)...<br>
> I have thus recompiled the VM with UB sanitizer, and there is indeed <br>
> some UB reported:<br>
> <br>
> ../../platforms/Cross/plugins/Squeak3D/b3dMain.c:1252:29: runtime error: <br>
> left shift of negative value -760<br>
> ../../platforms/Cross/plugins/Squeak3D/b3dMain.c:1254:25: runtime error: <br>
> left shift of negative value -751<br>
> ../../platforms/Cross/plugins/Squeak3D/b3dDraw.c:317:33: runtime error: <br>
> left shift of negative value -802<br>
> ../../platforms/Cross/plugins/Squeak3D/b3dDraw.c:318:33: runtime error: <br>
> left shift of negative value -802<br>
> ../../platforms/Cross/plugins/Squeak3D/b3dDraw.c:316:33: runtime error: <br>
> left shift of negative value -114<br>
> ../../platforms/Cross/plugins/Squeak3D/b3dMain.c:829:61: runtime error: <br>
> left shift of negative value -2<br>
> <br>
> Though, the instrumented fast VM does not fail...<br>
> It might be that some aggressive optimizations assuming the absence of <br>
> UB do not occur with all the instrumentation stuff embedded...<br>
<br>
This is very dark magic.<br>
<br>
> IMO, declaring a left shift of negative int UB is sort of FOOLISH.<br>
<br>
Tell me where to vote and I'll vote for you.<br>
<br></blockquote><div>You cannot yet vote for opinions, except on some social networks ;)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> We will have to protect each and every left shift in b3d with a cast...<br>
<br>
To see a good side in this, stumbling at this point upon this kind of <br>
errors must mean the 3D code in itself is quite sound. Indeed I had only <br>
a couple of similar crashes for hours of testing (well, playing).<br>
<br>
What I saw also a couple times, and which is more difficult to report, <br>
is the VM hanging at 100% CPU on its core and having to be killed <br>
externally. Could it be the same nasal demons at work?<br>
<br></blockquote><div>hard to say...</div><div>I think that you can send a SIGUSR1 to dump stacks, or attach a debugger to running VM....</div><div><br></div><div>Unfortunately, I also had another crash:</div><div><br></div><div>../../platforms/Cross/plugins/Squeak3D/b3dMain.c:954:43: runtime error: member access within null pointer of type 'B3DPrimitiveFace' (aka 'struct B3DPrimitiveFace')<br><br>Segmentation fault Sat Feb 8 21:19:37 2020<br><br>VM: 202002050212 nicolas@MBP-de-Nicolas:Smalltalk/OpenSmalltalk/opensmalltalk-vm<br>Date: Tue Feb 4 18:12:07 2020 CommitHash: 0f974af6a<br>Plugins: 202002050212 nicolas@MBP-de-Nicolas:Smalltalk/OpenSmalltalk/opensmalltalk-vm<br><br>C stack backtrace & registers:<br> eax 0x00000018 ebx 0x00000000 ecx 0x040835a8 edx 0x00000000<br> edi 0x040835a8 esi 0x040835a8 ebp 0xbfeec978 esp 0xbfeec940<br> eip 0x0f0584b5<br>0 Squeak3D 0x0f0584b5 b3dAddFrontFill + 118<br>1 Squeak 0x00275ea4 reportStackState + 870<br>2 Squeak 0x00276862 sigsegv + 353<br>3 libsystem_platform.dylib 0xa7dffbae _sigtramp + 46<br>4 ??? 0xffffffff 0x0 + 4294967295<br>5 Squeak3D 0x0f05a0ee b3dToggleTopFills + 604<br>6 Squeak3D 0x0f05cdc0 b3dMainLoop + 7239<br>7 Squeak3D 0x0f017adb b3dStartRasterizer + 1668<br></div></div></div></blockquote><div><br></div><div>And I see that this one more closely match your crash.dmp report...</div><div>So the negativeInt<<shift was another problem created by my clang version on OSX.</div><div>I ran a few times without crash, so thought it was thru, but your crash is not yet fixed...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Stef<br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>