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