[PD] gdb and Pd WAS: testtone comments

[Hans-Christoph Steiner]

On Nov 16, 2011, at 2:18 AM, Mathieu Bouchard wrote:

> Le 2011-11-15 à 22:03:00, Ivica Ico Bukvic a écrit :
> 
>> I have not been following this thread at all, but for what it's worth in my experience these kinds of seemingly illogical errors usually arise from memory corruption (typically because something has not been properly allocated).
> 
> That's why I go on and on about Valgrind and its magical abilities to find causes instead of consequences.
> 
> But I should also remark that code is easier to debug when it's not optimised :
> 
>> #1  0x000000000043c629 in pd_typedmess (x=0x830220, s=<optimized out>,     argc=<optimized out>, argv=<optimized out>) at m_class.c:812
> 
> as you can see, we're losing information, because the executable does stuff in a way that gdb doesn't understand, and some info is missing about how gdb could be reading it, when it's readable at all. Some variables disappear entirely, some only pretend to.
> 
> But more importantly, some function calls disappear, either because they are merged (due to any options named «inline»), or because it's faster to skip doing certain things that are required for producing good backtraces («omit-frame-pointer» also means some function calls become hidden).

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.

.hc

----------------------------------------------------------------------------

Using ReBirth is like trying to play an 808 with a long stick.    -David Zicarelli