[PD] gdb and Pd WAS: testtone comments

[Jonathan Wilkes]

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.

http://pastebin.com/TmyS2gbt

-Jonathan



----- 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 
> 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:
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=15771
> 
> .hc
> 
> ----------------------------------------------------------------------------
> 
> "[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 -> 
> http://lists.puredata.info/listinfo/pd-list
>