Ok, many thanks to all Wolfgang i suggest you to explain this LRESPR's "limit" in the next version of the SMSQ/E manual.
Giorgio 2017-02-23 6:19 GMT+01:00 Wolf <w...@wlenerz.com>: > Hi, > > Even if never fixed, any chance you could share what you found as the >> cause? >> >> > Sure thing. > > This is how I see the error arises: > > First > When you call the vector to initialise new keywords, the corresponding > routine (at label "sb_inipr" in smsq_sbas_inipr_asm) allocates new memory > for the new name table and much other information, shuffles the content of > the old into the new, de-allocates the old and does quite some more > shuffling/updating pointers. > > Second > Whenever one is in a procedure, at the end of the procedure, you come to > label "bo_return" (in the file smsq_sbas_iprocb_asm). Following the flow of > that you will arrive at the following code: > > bor_lvlend > cmp.l d4,d5 ; bottom of locals yet? > bgt.s bor_lvloop ; ... no > > move.l rt_def(a6,a2.l),d0 > neg.l d0 ; address of definition > > Unfortunately, the address D0 now points to (which is then copied into A4 > and used later) is now wrong. It still seems to point into some of the old > memory that was deallocated. > > Now, with a bit of luck, the content of that memory hasn't been re-used > between the call to sb_inipr and this point in the code, so that the > program can continue normally. If not, you will most likely get > into a heap error later: > > After the above code, just before you get to the loop at label > "bor_fploop", the adress in A4 is used to get the number of parameters to > treat. This is most likely wrong, so the loop counter for the loop is (in > the case I observed) much bigger than what it should have been (note this > could also have happened at label "bor_swloop" a bit earlier on). In the > loop at label "bor_fploop" there most likely will be a cbra to label > "bor_fpex" to clear the (local) variables used in the procedure via the > subroutine at label "bor_clrval". > > This leads to label "sb_redat" (in smsq_sbas_aldat_asm) from there to > "sad_rlx". This tries to release momory taken up by the (local) variables > and, since one does that more often that is should have been, may lead to a > heap error at label "sad_error": > sad_error > dc.l $4afbedeb > bra.s sad_error > dc.w 'HEAP' > which will cause the program to hang. > > Releasing mem that shouldn't have been could also lead to other > interesting errors... > > Coming back to the initial error: > > bor_lvlend > cmp.l d4,d5 ; bottom of locals yet? > bgt.s bor_lvloop ; ... no > > move.l rt_def(a6,a2.l),d0 > neg.l d0 ; address of definition > > Interestingly, the area pointed to by (A6,A2) was indeed copied from the > old mem to the new - unfortunately, the pointer at rt_def(a6,a2.l) within > that was not updated. > Finding out where that pointer originally pointed to and then trying to > set it to the corresponding new memory location does not seem trivial to > me, and the risk of breaking the entire program just seems too great to me. > I'd love to be proved wrong... > > Have fun > > Wolfgang > > _______________________________________________ > QL-Users Mailing List > _______________________________________________ QL-Users Mailing List
