<div dir="ltr"><div>Hi all,</div><div>and I probably broke it with <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/448">https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/448</a></div><div>The function signature was already BADLY unconsistent!</div><div>But luckily, the erroneous 64 bits arguments did get copied into 32 bits dstY before my fix...</div><div>I sort of broke the spell and the magic vanished ;)<br></div><div>Brittle code = hazardous life</div><div><br></div><div>What I'm very unsure of now, is if writing at negative offset is a good idea (buffer underflow?), or if this uncovers yet another bug at upper level...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 9 janv. 2020 à 23:12, 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>I note a few bad things:</div><div><br></div><div>* thread #1, queue = 'com.apple.main-thread', stop reason = Invalid shift base<br> * frame #0: 0x0000000100ad5f40 libclang_rt.ubsan_osx_dynamic.dylib`__ubsan_on_report<br> frame #1: 0x0000000100ad05f8 libclang_rt.ubsan_osx_dynamic.dylib`__ubsan::Diag::~Diag() + 216<br> frame #2: 0x0000000100ad32d1 libclang_rt.ubsan_osx_dynamic.dylib`handleShiftOutOfBoundsImpl(__ubsan::ShiftOutOfBoundsData*, unsigned long, unsigned long, __ubsan::ReportOptions) + 929<br> frame #3: 0x0000000100ad2f24 libclang_rt.ubsan_osx_dynamic.dylib`__ubsan_handle_shift_out_of_bounds + 68<br> frame #4: 0x000000011036fb5c Squeak3D`b3dMainLoop(state=0x00000001103aa990, stopReason=0) at b3dMain.c:1249:29</div><div>../../platforms/Cross/plugins/Squeak3D/b3dMain.c:1249:29: runtime error: left shift of negative value -8</div><div><br></div><div>same at following lines</div><div> frame #4: 0x000000011036fbca Squeak3D`b3dMainLoop(state=0x00000001103aa990, stopReason=0) at b3dMain.c:1251:25</div><div> frame #5: 0x0000000110373c6a Squeak3D`b3dMainLoop(state=0x00000001103aa990, stopReason=0) at b3dMain.c:1428:8</div><div> frame #5: 0x0000000110373c6a Squeak3D`b3dMainLoop(state=0x00000001103aa990, stopReason=0) at b3dMain.c:1428:8</div><div>Don't you rely on UB !</div><div><br></div><div>Then at crash site:</div><div>Process 95068 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x321089be150)<br> frame #0: 0x00000001003c58fd Squeak`alphaSourceBlendBits32 at BitBltPlugin.c:820:5<br> 817 sourceWord = long32At(srcIndex);<br> 818 srcAlpha = ((usqInt) sourceWord) >> 24;<br> 819 if (srcAlpha == 0xFF) {<br>-> 820 long32Atput(dstIndex, sourceWord);<br> 821 srcIndex += 4;</div><div><br></div><div>we have :</div><div>(lldb) p/x dstIndex<br>(sqInt) $9 = 0x00000321089be150</div><div>(lldb) p/x destBits<br>(sqInt) $14 = 0x00000001089be470</div><div><br></div><div>Wow, dstIndex is very far from destBits... because:</div><div>(lldb) p/x dy<br>(sqInt) $13 = 0x00000000ffffffff<br></div><div>(lldb) p/x dstY<br>(sqInt) $15 = 0x00000000ffffffff<br></div><div><br></div><div>Hmm is that intended to be so large? or just -1?</div><div>Is it a missing sign extension?</div><div>Is -1 a valid value?</div><div><br></div><div>it comes from destY, which is set either by BitBlt inst var access:</div><div>destY = fetchIntOrFloatofObjectifNil(BBDestYIndex, bitBltOop, 0);</div><div><br></div><div>or thru balloon support:</div><div>EXPORT(sqInt)<br>copyBitsFromtoat(sqInt startX, sqInt stopX, sqInt yValue)<br>{<br> destX = startX;<br> destY = yValue;</div><div><br></div><div>We are in the later case:</div><div>(lldb) bt<br>* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x321089be150)<br> * frame #0: 0x00000001003c58fd Squeak`alphaSourceBlendBits32 at BitBltPlugin.c:820:5<br> frame #1: 0x00000001003bf07d Squeak`copyBitsLockedAndClipped at BitBltPlugin.c:1438:3<br> frame #2: 0x00000001003b97e6 Squeak`copyBits at BitBltPlugin.c:1257:2<br> frame #3: 0x00000001003b9893 Squeak`copyBitsFromtoat(startX=0, stopX=199, yValue=4294967295) at BitBltPlugin.c:1357:2<br> frame #4: 0x000000011036eeb4 Squeak3D`b3dDrawSpanBuffer(aet=0x0000000108a313c8, yValue=-1) at b3dMain.c:1146:3<br> frame #5: 0x0000000110373d5b Squeak3D`b3dMainLoop(state=0x00000001103aa990, stopReason=0) at b3dMain.c:1448:4<br> frame #6: 0x000000011030e1e1 Squeak3D`b3dStartRasterizer at Squeak3D.c:1704:12<br> frame #7: 0x00000001000b9cc4 Squeak`primitiveExternalCall at gcc3x-cointerp.c:76948:3</div><div><br></div><div>up the stack, we have:</div><div>/* INLINE b3dDrawSpanBuffer(aet, yValue) */<br>void b3dDrawSpanBuffer(B3DActiveEdgeTable *aet, int yValue)<br>{<br> int leftX, rightX;<br> if(aet->size && currentState->spanDrawer) {<br> leftX = aet->data[0]->xValue >> B3D_FixedToIntShift;<br> rightX = aet->data[aet->size-1]->xValue >> B3D_FixedToIntShift;<br> if(leftX < 0) leftX = 0;<br> if(rightX > currentState->spanSize) rightX = currentState->spanSize;<br> currentState->spanDrawer(leftX, rightX, yValue);<br> }<br>}</div><div><br></div><div>in b3d.h, we have:</div><div> /* Function to call on drawing the output buffer */<br> b3dDrawBufferFunction spanDrawer;</div><div><br></div><div>and what is a b3dDrawBufferFunction?</div><div>typedef int (*b3dDrawBufferFunction) (int leftX, int rightX, int yValue);</div><div><br></div><div>OK, so we get a type mismatch on x64...</div><div>We pretend that the function expects a 32bits int, when it expects a 64bits sqInt...</div><div>Bad, because this type mismatch prevents the sign extension...</div><div>Parameter is pased on a 64 bit register, and we get the high bits remaining at 0...</div><div><br></div><div>So it's a bit more subtle than pointer stored into int.</div><div>Frankly, those type mismatch are a plague.</div><div>Levente just corrected a bunch of them recently, but when there is such an indirection thru a function pointer, it's getting unobvious...</div><div>Especially when we force with a cast:</div><div><br></div><div>../src/plugins//Squeak3D/Squeak3D.c: state.spanDrawer = (b3dDrawBufferFunction) copyBitsFn;</div><div><br></div><div>../src/plugins/Squeak3D/Squeak3D.c:static sqInt copyBitsFn;<br>../src/plugins/Squeak3D/Squeak3D.c: copyBitsFn = ioLoadFunctionFrom("copyBitsFromtoat", bbPluginName);</div><div><br></div><div>Bah, with all those casts, we let ZERO chance to the compiler to tell us the awfull type mismatch!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 9 janv. 2020 à 22:18, Phil B <<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@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">I can confirm that at least basic functionality of the plugin is working on 64-bit x86 Linux (and 32-bit x86 and ARM) since I use it almost daily. However I'm only using it to create/manage the 3D viewport... everything else I'm doing via FFI. (i.e. if there is other functionality that is broken, I likely wouldn't be seeing it)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at 11:48 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<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"><div dir="ltr">Hi Dave,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 9, 2020 at 6:04 AM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<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>
On Thu, Jan 09, 2020 at 12:57:23PM +0100, St??phane Rollandin wrote:<br>
> <br>
> Hello all,<br>
> <br>
> I have had a report that the code for my Balloon3D-based game (at <br>
> <a href="http://www.zogotounga.net/comp/guardians.htm" rel="noreferrer" target="_blank">http://www.zogotounga.net/comp/guardians.htm</a>) does not work at all on <br>
> 64-bit images.<br>
> <br>
> The report was about a linux system, and indeed I could confirm that it <br>
> also applies on Windows.<br>
> <br>
> I have uploaded a ready-to-crash trunk image here, with instructions:<br>
> <a href="http://www.zogotounga.net/swap/crash-64.zip" rel="noreferrer" target="_blank">http://www.zogotounga.net/swap/crash-64.zip</a><br>
> <br>
> Note that no crash dump is produced.<br>
<br>
<br>
Hi Stef,<br>
<br>
I am fairly sure that the Squeak3D plugin was never updated for 64-bit<br>
platforms, so it probably will not work on any 64-bit VM.<br>
<br>
Updating a plugin like this mostly requires finding and fixing all the<br>
places where pointer values are assigned to C int variables. For most<br>
of the plugins, this involved some changes to both the platform support<br>
code (C code in git) as well as to the plugin in VMMaker.<br>
<br>
Is anyone interested in taking on a worthwhile VM project with manageable<br>
scope? Updating the Squeak3D plugin would be a good project. I can give<br>
some tips and advice if anyone wants to give it a try.<br></blockquote><div><br></div><div>The Squeak3D polygon was updated for 64 bits. It is built and included as an external plugin on all 32 bit and 64 bit Spur VMs. It builds with only one (expected) warning:</div><div><br></div><div><div>../../src/plugins/Squeak3D/Squeak3D.c:6:13: warning: unused variable '__buildInfo' [-Wunused-variable]</div><div>1 warning generated.</div></div><div><br></div><div>So whatever the issue is is deeper than simply not having been updated.</div></div><br><div dir="ltr"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>