Re: Detecting endless recursion?

Lex Spoon <lex@cc.gatech.edu>
1 Feb 2004 13:00:05 -0500

          From comp.compilers

Related articles
[16 earlier articles]
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-02-01)
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-02-01)
Re: Detecting endless recursion? joachim.durchholz@web.de (Joachim Durchholz) (2004-02-01)
Re: Detecting endless recursion? joachim.durchholz@web.de (Joachim Durchholz) (2004-02-01)
Re: Detecting endless recursion? nmm1@cus.cam.ac.uk (2004-02-01)
Re: Detecting endless recursion? derkgwen@HotPOP.com (Derk Gwen) (2004-02-01)
Re: Detecting endless recursion? lex@cc.gatech.edu (Lex Spoon) (2004-02-01)
Re: Detecting endless recursion? bear@sonic.net (Ray Dillinger) (2004-02-04)
Re: Detecting endless recursion? nmm1@cus.cam.ac.uk (2004-02-04)
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-02-04)
Re: Detecting endless recursion? joachim.durchholz@web.de (Joachim Durchholz) (2004-02-08)
Re: Detecting endless recursion? alexc@std.com (Alex Colvin) (2004-02-08)
Re: Detecting endless recursion? cymric73@hotmail.com (Maarten D. de Jong) (2004-02-08)
[4 later articles]
| List of all articles for this month |

From: Lex Spoon <lex@cc.gatech.edu>
Newsgroups: comp.compilers
Date: 1 Feb 2004 13:00:05 -0500
Organization: Georgia Institute of Technology
References: 04-01-050 04-01-086 04-01-119 04-01-123 04-01-149
Keywords: debug, optimize
Posted-Date: 01 Feb 2004 13:00:05 EST

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


Post a followup to this message

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