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.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Marvin Humphrey marvin@rectangular.com Cc: pd-list pd-list@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&revi...
.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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list