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 <[email protected]> > To: Marvin Humphrey <[email protected]> > Cc: pd-list <[email protected]> > 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 > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
