[PD] gdb and Pd WAS: testtone comments

[Marvin Humphrey]

On Wed, Nov 16, 2011 at 09:46:18AM -0500, Hans-Christoph Steiner wrote:
> To this end, I recently did some work on the Pd-extended build system to
> make sure that everything gets built with -g -fno-omit-frame-pointer.  With
> those two, I have found that you can get good info while still having the
> (other) optimizations in.  Debugging with the optimizations is also
> important since that's how most people actually use pd.

Certainly, compiling with those flags aids debugging with gdb and
optimizations enabled.

Nevertheless, I have to say that while I've used Valgrind to debug countless
memory glitches, I have only tracked the problem down to an
optimization-related compiler bug once.  Memory corruption bugs and leaks seem
to originate much more often with the programmer than the compiler. :) 

To fully exploit Valgrind and its ability to identify ordinary C programmer
error, it's convenient (though not required) to build with optimization off
and -fno-inline-functions so as to make building suppressions files easier.
That's not going to hide bugs like double-frees, buffer overruns, etc, and
most of the time, that's what at the root of the problem.

I would also like to second Matju -- it is much more useful to know the moment
the invalid write occured than it is to know what happened at the moment the
corrupted memory caused the crash.  Heap memory corruption in particular is a
spooky-action-at-a-distance phenomenon[1] -- there is usually no obvious
cause-and-effect relationship between the bad write and its eventual
consequences, because overwriting the heap's bookkeeping records causes stuff
to go haywire in really weird ways at unpredictable moments.  It is much
easier to debug starting from the cause that Valgrind identifies rather than
starting from the effect that gdb identifies. 

Marvin Humphrey

[1] http://en.wikipedia.org/wiki/Action_at_a_distance_%28computer_science%29