[PD] gdb and Pd WAS: testtone comments

Hans-Christoph Steiner hans at at.or.at
Wed Nov 16 17:58:02 CET 2011

On Nov 16, 2011, at 11:03 AM, Marvin Humphrey wrote:

> 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

Ok, I added -fno-inline-functions and streamlined the global debug flags.  Tomorrow's builds should be ready for full valgrind action!

Here's the commit:



"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."        -John Gilmore

More information about the Pd-list mailing list