[PD] debugging techniques/tricks for a non-developer?

[Mathieu Bouchard]

On Sat, 3 Nov 2007, Matteo Sisti Sette wrote:

> However, there are situations in which I can't even isolate the problem and
> that's scary because if you don't know what conditions trigger the
> bug/issue,

run pd inside valgrind. it slows down pd by 50 times or so, but it checks 
a lot more memory accesses, and it can make the bugs easier to trigger.

sometimes bugs remain silent because they only do memory corruption 
without trying to access non-existent memory. this can confuse the rest 
of the program and make it do something it shouldn't do. Eventually this 
leads to a crash. This makes bugs more difficult to trigger and very 
difficult to track. this is why you need valgrind.

valgrind is still unable to figure out stack corruption. i had to move an 
array to the heap (using malloc and free) in order to witness that the 
code was writing to element [-1] "of" the array, which is actually a 
different variable. this access is only caught by valgrind: gdb wouldn't 
figure it out, because it does not look for that.

> If PD crashes, I need to know: whether there is or not an error in my patch,

a segfault or bus error or other sudden crash is always considered the 
fault of C code, never of patches.

an almost-infinite loop involving [until] is considered fault of the user, 
even though the user can't force pd to quit the loop. this would deserve 
some feature to force breaking out of the loop, but in itself it's not a 
bug in pd.

the use of too much RAM could be blamed on either pd itself, on externals 
or on pd patches, it depends how it's done. if the memory can't be 
recovered by doing something in pd, such as deleting some hungry objects, 
then it's probably the fault of pd or externals.

> In such a situation, would there be any means to figure out at least what
> abstraction contained the "guilty" loadbang? (then it may help or not,
> because there may be 100 instances of that abstraction all around, but it
> would be a starting point)

gdb and valgrind can produce listings of function-activations ("stack 
frames") which will usually be fairly effective at finding the source of a 
problem in a C file, but it takes some special commands to get at info 
like "what's the chain of patches for going back to the main patch?", that 
is, the road to reaching the object when you open the main patch.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada