[PD] debugging techniques/tricks for a non-developer?
matju at artengine.ca
Sun Nov 4 21:44:04 CET 2007
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
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
More information about the Pd-list