Re: Detecting endless recursion?

torbenm@diku.dk (Torben Ęgidius Mogensen) writes:




>> 2: Recompile for debugging, or insert your own tracing of function
>> returns, and the program fails before it reaches the code you are
>> testing. The best 'solution' to this that I was told was to use a
>> supercomputer for debugging the codes you are intending to run on a
>> low-end PC :-)
>
> Now you're trolling. Scheme has many debugging tools that don't break
> tail-recursion (or GC).


It's not at all a troll. The tail-call optimization does make
debugging more difficult -- please review the post again. Further,
removing the optimization can cause programs that need it to fail, and
thus sometimes you can end up in a situation where you cannot debug
the program on your regular PC; you would need a computer with enough
memory that the tail call optimization is not necessary.


It would appear that there is still a solution, even in this toughest
case, but I don't know if anyone implements it. It goes like this.
You could have a debugging execution mode where tail calls are not
erased immediately; instead, when the stack grows large, tail calls
deep in the stack are coallesced to free up space. To make things
easy, heap-allocate all activations so that you can easily delete from
the middle of the stack. To make this nicer on the user, insert a
marker at any location you remove stack activations, so that the
debugger will be able to tell the truth about what has happened.


Various strategies are available for picking which activations to
remove. You surely do not want to remove things near the top of the
stack, because that is the most likely thing the user will want to
look at. You *might* not want to remove things from near the bottom,
similarly, because the user may want to see what triggered the current
chain of events. The best choice seems to be to aim for the middle of
the stack. Further, it would seem better to prefer activations that
have direct recursion or mutual recursion as much as possible, in
order to decrease the likelihood that the user wanted that particular
frame.




-Lex

Return to the comp.compilers page.
Search the comp.compilers archives again.