[PD] gdb and Pd WAS: testtone comments
jancsika at yahoo.com
Thu Nov 17 01:14:07 CET 2011
Below is a valgrind log-- I just kept opening and closing about.pd and it never actually crashed. The "conditional jump" stuff
happened when I clicked the big green [bng] and started the ds animation.
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Marvin Humphrey <marvin at rectangular.com>
> Cc: pd-list <pd-list at iem.at>
> Sent: Wednesday, November 16, 2011 11:58 AM
> Subject: Re: [PD] gdb and Pd WAS: testtone comments
> 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
>>> make sure that everything gets built with -g -fno-omit-frame-pointer.
>>> those two, I have found that you can get good info while still having
>>> (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
>> memory glitches, I have only tracked the problem down to an
>> optimization-related compiler bug once. Memory corruption bugs and leaks
>> 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
>> 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,
>> 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
>> the invalid write occured than it is to know what happened at the moment
>> corrupted memory caused the crash. Heap memory corruption in particular is
>> spooky-action-at-a-distance phenomenon -- 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
>> to go haywire in really weird ways at unpredictable moments. It is much
>> easier to debug starting from the cause that Valgrind identifies rather
>> starting from the effect that gdb identifies.
>> Marvin Humphrey
> 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
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list