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
