On Jul 29, 2009, at 8:50 AM, Mike Eggleston wrote:
On Wed, 29 Jul 2009, Eli Barzilay might have said:
On Jul 29, Mike Eggleston wrote:
Yes, much, and preferable in a production environment when you're
trying to figure out why something is not right. Any change you make
to the code must be tested again, so if you can run the code through
a debugger without changes is best. If you make a change to add
printf()s then you can't say for certain if your printf() caused the
error or if you've found the reported error.
This point is bogus. I personally had one occasion where I had spent
about 14 hours chasing a problem that we discovered in a release mode
build of our product. It was there for about a week before that (and
it was the segfaulting kind of a problem), yet we didn't know about
it
because it didn't happen in debug mode.
Not bogus for me. I perform this type of debugging often on production
systems. I like to know I have made no changes to a system I'm trying
to find the error in, that I've not introduced another issue by
changing
the code to add printf()s (stdout or file).
I agree with Eli, and have experienced the same myself in C/C++
debugging. Usually the debugger *does* have an effect on the system
you're running (like it might set pointers to NULL instead of leaving
them uninitialized garbage values). It's the CS counterpart of the
"observer effect"...
http://en.wikipedia.org/wiki/Observer_effect_(physics)
I would rather trust printf's (of course without side-effect
expressions in their arguments) than a debugger.
--- nadeem
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-scheme
