[plt-scheme] debugging [mini rant]

From: Nadeem Abdul Hamid (nadeem at acm.org)
Date: Wed Jul 29 09:01:46 EDT 2009

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

Posted on the users mailing list.