Dear ChucKists, Another day, another novel and exciting way to get the whole VM stuck; Wurely w => dac; 1.0 / 0 => w.freq; 1 => w.noteOn; second => now; At a frequency of infinity (which admittedly is a bit silly but it happened by accident...) Wurley (and probably the other FM instruments as well, I imagine) gets completely stuck and takes 100% CPU time. This is quite understandable but what's not so nice is that this gets the whole VM stuck as well. Watchdog will offer to stop the shred (in the Mini) but fails... so that forces us to quit the whole thing the hard way. I think LiSa can cause a similar situation if we request a lot of voices very quickly, say one every few ms, and she runs out of voices (I'm not yet certain about the exact conditions there). Generally it seems like watchdog is unable to remidy the situation if it's a UGen and not a shred that gets stuck. I'm not sure how we should deal with this. Perhaps there could be some way to get watchdog to interupt UGens, or perhaps we should sanitise UGen function calls. I'm not sure, for example, whether there is a perceived need for fm electrical pianos to accept frequencies above the nequist... It probably can't be avoided that some things will get suck under some conditions but I would like to have some safeguards against this taking down the whole VM, where possible. Yours, Kas.
I would think the best approach would be to actually limit the
accepted frequency, and not access NaN for example. But for a
watchdog-style approach, I bet it wouldn't be difficult to implement
an "abort" flag in each shred that can be set to 1, and gets checked
between sample computations. Not sure how it's done now, perhaps
something similar.
Steve
On Fri, Sep 19, 2008 at 2:53 AM, Kassen
Dear ChucKists,
Another day, another novel and exciting way to get the whole VM stuck;
Wurely w => dac; 1.0 / 0 => w.freq; 1 => w.noteOn; second => now;
At a frequency of infinity (which admittedly is a bit silly but it happened by accident...) Wurley (and probably the other FM instruments as well, I imagine) gets completely stuck and takes 100% CPU time. This is quite understandable but what's not so nice is that this gets the whole VM stuck as well. Watchdog will offer to stop the shred (in the Mini) but fails... so that forces us to quit the whole thing the hard way.
I think LiSa can cause a similar situation if we request a lot of voices very quickly, say one every few ms, and she runs out of voices (I'm not yet certain about the exact conditions there).
Generally it seems like watchdog is unable to remidy the situation if it's a UGen and not a shred that gets stuck. I'm not sure how we should deal with this. Perhaps there could be some way to get watchdog to interupt UGens, or perhaps we should sanitise UGen function calls. I'm not sure, for example, whether there is a perceived need for fm electrical pianos to accept frequencies above the nequist... It probably can't be avoided that some things will get suck under some conditions but I would like to have some safeguards against this taking down the whole VM, where possible.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Stephen;
I would think the best approach would be to actually limit the accepted frequency, and not access NaN for example.
That would be good, but it would go at the expense of our options in controlled aliasing, a technique that may have valuable artistic uses to some. It could still be a good trade here. I like the NaN idea in any case, I don't think we can expect Wurley to deal with "inf", even if it *is* a float :¬).
But for a watchdog-style approach, I bet it wouldn't be difficult to implement an "abort" flag in each shred that can be set to 1, and gets checked between sample computations. Not sure how it's done now, perhaps something similar.
Yes, I was thinking along those lines as well. ChucK is too large and complicated to avoid the possibility of things going wrong and as we say; "powertools can maim" but I don't like stuff bringing down the whole VM. Right now, for example, a integer div. by 0 will take out the whole VM without any comment which I think is a bit much. Dropping that shred seems far more reasonable. I also wonder how different things are if we supply .freq() functions with values that are merely very, very high instead of being infinity. Right. I feel this responce to "inf" as a frequency parameter is sufficiently bothersome to call it a issue for the bug page. I'll add it there and if somebody disagrees we can take it off again. Yours, Kas.
participants (2)
-
Kassen -
Stephen Sinclair