Re: [plt-scheme] debugging [mini rant]

2009/7/29 Robby Findler <robby@xxxxxxxxxxxxxxxxxxxxx>:
> On Wed, Jul 29, 2009 at 7:50 AM, Mike Eggleston<mikeegg1@xxxxxxx> 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).
>
> No to belabor the obvious here, but debuggers change the behavior of
> your program (perhaps even more than printfs, depending on what you're
> doing).

Sometimes they do it to help you diagnose problems early. For
instance, Visual C++ debugger  fills memory with special bytes  both
on allocation and on release to help you spot invalid memory accesses.

IMO, debuggers are not perfect, but a hell of help when dealing with
legacy code.
_________________________________________________
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme