From: Bob Carragher (bob_at_fla.fujitsu.com)
Date: Fri Mar 17 2000 - 23:11:58 GMT
russ_at_amc.com (Russell Browne) writes: > Bob Carragher wrote: > > > By the way, Ian Edward's suggestion of using Purify is > > practically useful, but it doesn't help with proseletizing > > UPS. ... > > To investigate infinite recursion, set a breakpoint in the offending > function and edit to look like > > static int i=0; if (i++ > 1000) #stop; > > The should break the process well into the offending call, even if > there are a few valid calls first, but well before the stack overflows. > > Ask your gdb fans how to do that! > > I think how well it handles infinite recursion is a rather > minor point in choosing a debugger. Some ups features that > I find far superior to other debuggers I have tried: > > [Many good features deleted.] The debugger that my friend uses is a Sun product which "integrates" xemacs and xdbx with lots of extras so that you get a "source-based" debugger environment similar to what is available on PCs. In particular, you can make changes in the code in the original source file and then click "run" and it will compile and link and run the executable under the debugger, maintaining the previous session's breakpoints. Quite frankly, I prefer the UPS approach. Sure, you have to close the UPS session, recompile/link, then restart the debugger. But you've also saved so much state information, plus whatever breakpoints you want, that you get the same result. Also, if typing "make" doesn't give you the executable that you're looking for, then you're probably stuck with the Sun version. Ah well, he can be less productive if he wants. B-) Bob
This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:51:33 GMT