Hi,
I use PD quite a lot, and it sometimes happens to me that it crashes. Sometimes I have been able to isolate and identify the cause of the crash, in which case either it was a known bug or I reported it, or the crash was triggered by some errors in my patches that I could fix.
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, you cannot feel sure that it won't happen on-stage just because it hasn't happened for a long time lately..... If PD crashes, I need to know: whether there is or not an error in my patch, and if there isn't, how to avoid the crash condition.
So my question is....
Is there some way one can, for instance, figure out some information about "where" the crash happened, if not "why"?
For example, once I realized that some patch of mine made PD crash when I opened it, but it didn't if I opened it with -noloadbang So the crash must be provoked by some loadbang, be it because of a PD bug or of an error in my patch. However my patch was quite "big" and had a lot of abstractions with a lot of loadbangs so it was impossible to figure out which one(s) triggered the patch... and I never did. It just stopped happening. 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)
I guess that, if I had such a thing as Visual C++ and if I were a skilled developer and if I were familiar with PD sourcecode, I coud debug and figure out things... but none of these conditions holds true.
I'm interested in any kind of (feasible) trick that can help one get any kind of useful information as to what provokes a crash, at least in the case one is able to reproduce (if not isolate) it.
In WINDOWS if possible. (I would like to become familiar with Linux, but hey, let's make one step at a time)
By the way, is it very difficult for a newbie to get started with recompiling PD's source code? (not only with the abovementioned aim but more in general: in a future I would like to learn a bit about its source code and even try playing with it) and in this case, running it in some sort of debug environment? What would I need? I do have programming skills, just not in C++ (and I do have a very basic knowledge of C++). I usually work only with high-level and interpreted languages.... well... PD is one of them!
Thanks in advance m.
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
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.
On Wed, 7 Nov 2007 12:42:12 +0100 "Matteo Sisti Sette" matteosistisette@gmail.com wrote:
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.
Isn't this the whole point of pd-watchdog? If not then it should be.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
Mathieu Bouchard -
Matteo Sisti Sette