<div dir="ltr"><div><div><div>I can reproduce this on x86_64. I spent a while poking around with gdb, but it was only afterwards that I realised that I'd seen the cause of the bug...<br><br>(gdb) frame 7<br>#7 0x000000000044efd0 in FORMATION_SET_EDITOR () at build/subs.rbas.bas:1036<br>1036 draw_formation_slices form, rootslice, -1, dpage<br>(gdb) p form<br>No symbol "form" in current context.<br>(gdb) p FORM<br>FORM$1 FORMATION_EDITOR FORMAT_DATE FORMAT_PERCENT_COND FORM_ID$1<br>FORMATIONS FORMATION_SET_EDITOR FORMAT_PERCENT FORMSET$1 FORM_ID$1.12413<br>(gdb) p FORM_ID$1<br>$4 = 0<br>(gdb) p FORM_ID$1.<br>Display all 200 possibilities? (y or n)<br>(gdb) p FORM_ID$1.12413<br>A syntax error in expression, near `.12413'.<br><br></div>Notice the 'if' check:<br> IF <a href="http://state.pt" target="_blank">state.pt</a> >= 4 AND form_id >= 0 THEN<br> draw_formation_slices form, rootslice, -1, dpage<br><br></div>form_id is -1 when there is no formation the slot, and hence rootslice is NULL. For some reason, according to gdb there are two form_id variables, and while I confirmed that form_id is -1 inside the lpreviewform gosub, as you can see above, form_id is 0 outside the gosub!<br></div><div>Next I had a look at the C code that fbc emitted, and there's only one form_id variable. I'm really surprised that gdb knows that there's a second form_id variable, which isn't apparent in the C code (is it listed in the debug info for this function, or did it deduce it?), or what the .12413 suffix means (it's not a line number).<br><br></div><div>So, of course, what's happening here is that when using -gen gcc GOSUB/RETRACE is implemented using setjmp/longjmp. Sure enough, the man pages for those states that local variables which aren't marked 'volatile' may or may not be restored by longjmp. GCC has stored form_id in a register, so longjmp *reverts* its value to 0 on the RETRACE. This problem didn't occur when I tested setjmp/longjmp GOSUBs without -gen gcc years ago (you can edit <a href="http://config.bi" target="_blank">config.bi</a> to enable that), because fbc is not an optimising compiler, and never keeps variables in registers.<br><br></div><div>fbc actually has an option to implement normal GOSUB/RETURN with setjmp/longjmp, so I should also check whether this problem affects standard FB under -gen gcc.<br></div><div><br></div><div>So to conclude, GOSUB is currently broken under -gen gcc and must not be used. This finally explains why we had to get rid of them in Game to get it to work on Android (one of those things that's been on the Android TODO list).<br></div><div>What's the solution? Since it isn't possible to put inline C in FB files, and it isn't possible to use FB's builtin GOSUB (if that happens to do something special so that it works) since that requires -lang deprecated, getting rid of GOSUB appears to be the only solution.<br><br>We're pretty close to being rid of GOSUB. There are only 33 GOSUBS and 18 RETRACEs left in the codebase, and there appear to be 17 GOSUB blocks, of which 11 are only called once, so GOSUB/RETRACE can just be converted to GOTO as a quick-fix rather than needing to be converted into a SUB. Number of occurrences of each GOSUB:<br> 1 drawing.bas:GOSUB disable<br> 1 drawing.bas:GOSUB drawoval<br> 1 drawing.bas:GOSUB drawsquare<br> 1 drawing.bas:GOSUB floodfill<br> 1 drawing.bas:GOSUB putdot<br> 1 drawing.bas:GOSUB readundospr<br> 1 drawing.bas:GOSUB replacecol<br> 3 drawing.bas:GOSUB resettool<br> 5 drawing.bas:GOSUB setupsample<br> 2 drawing.bas:GOSUB spedbak<br> 1 drawing.bas:GOSUB sprayspot<br> 1 drawing.bas:GOSUB sprctrl<br> 1 drawing.bas:GOSUB straitline<br> 1 mapsubs.bas:GOSUB mapping<br> 9 subs4.bas:GOSUB vehmenu<br> 3 subs.rbas:GOSUB lpreviewform<br><br></div><div>What do you know, most of them are in the graphics editors, which need to be majorly refactored anyway. <br></div><div><br></div><div><br></div>Next time you see a 64-bit specific bug, compile with scons gengcc=1 to try to reproduce it; the gcc emitter is more likely to be the cause than the architecture.<br><div><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 November 2016 at 11:31, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><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>Taoki confirmed that this change does indeed fix the crash he was seeing in the formation set editor.<br></div></div><div class="gmail-m_9006330510707549685HOEnZb"><div class="gmail-m_9006330510707549685h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 11, 2016 at 2:24 PM, <span dir="ltr"><<a href="mailto:subversion@hamsterrepublic.com" target="_blank">subversion@hamsterrepublic.co<wbr>m</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">james<br>
2016-11-11 14:24:57 -0800 (Fri, 11 Nov 2016)<br>
99<br>
SUBify the GOSUB/RETRACE block that loaded the hero formation previews in the formation set editor<br>
---<br>
U wip/subs.rbas<br>
______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div>