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.
Thanks a lot for the information and advice. The time has come to stop being lazy and get Linux!
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.
Yes, of course. A program should never ever crash, no matter how bad the input. Some of the crasher bugs of PD only produce the crash when there is an error in the patch, which doesn't mean they are not bugs, nor that they are not serious bugs (when you have an error in your patch you really need PD to give you a clear error message!), but it does mean that if you know it you can get rid of the problem by fixing the patch, and sleep peacefully.
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.
Indeed, you should ALWAYS be able to at least save the patch and close it. In my opinion, PD simulates a virtual machine, and the patch is the code executed by the virtual machine. So it's ok that you can write code that "virtually" crashes the "virtual" machine and/or makes it "virtually" unresponsive. However, the "simulator" itself, which is a "real" application running on a "real" machine , should never become unresponsive to user actions such as closing or saving the file. If it does, it is in my opinion a bug (or a design flaw), no less than if it crashes. It is especially important since in this case PD is at the same time the interpreter and the editor, so if it hangs you may loose your work.