| Author |
Message |
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
 Posted: Tue Feb 20, 2007 11:21 am Post subject:
 Warning: don't forget to advance time in the main loop |
  |
|
I'm a ChucK newbie, and I haven't read through all topics here, but I couldn't find anything with this headline (or the keyword "freeze" in a search here and at the chuck wiki), so I thought maybe I'll save somebody from being a stupid ass and doing like I did:
while(true) {
}
in the main loop. My computer completely froze and the restart button was called for. I know, this is really stupid, and no one else is probably going to suffer. 
Maybe a good thing would be to make some kind of bail-out mechanism if time hasn't been advanced for 10 minutes or something...
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
 |
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Tue Feb 20, 2007 12:03 pm Post subject:
Re: Warning: don't forget to advance time in the main loop |
|
|
| Quote: | while(true) { }
in the main loop. My computer completely froze and the restart button was called for. I know, this is really stupid, and no one else is probably going to suffer. |
Indeed - this will cause chuck to lose its mind and effectively take so much cpu cycles as to "freeze" the computer. It's not just in the main loop either, but a sufficiently infinite loop in any shred will do the same when run, especially if the loop does little or no work.
| Quote: | | Maybe a good thing would be to make some kind of bail-out mechanism if time hasn't been advanced for 10 minutes or something... |
This has been a long standing issue, and we hope to one day fix it. There is a "watchdog" mechanism in place, which will attempt to lower the priority of the VM thread - it works sometimes but can often take too long to be useful.
Looking at the source, I see that this feature is disabled by default. You can enable it with the --watchdog flag, though that's just not useful since not many people are going to run the thing expecting to kill the universe with empty loops. We'll likely re-enable it in the next version.
Our apologies about this! We hope to find a better solution. |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Tue Feb 20, 2007 12:05 pm Post subject:
|
|
|
| one more thing, what platform OS did this happen on? In general, the chuck implosion happens across the board, but in slightly different ways on different systems. |
|
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
| Posted: Tue Feb 20, 2007 12:58 pm Post subject:
|
|
|
Thanks for your info! I'm running ChucK in cygwin on a Windows XP SP2 machine - AMD 64.
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Feb 20, 2007 1:51 pm Post subject:
Re: Warning: don't forget to advance time in the main loop |
|
|
I'd also like to go back a bit and look at *why* You'd like to have a "main loop" that consists of only;
I'm going to asume that this is to keep shreds you sporked so far alive, right?
Next time you coud try this;
| Code: |
Event the_end;
the_end => now; |
This will define a event, then wait for it to happen. Then we'll simply never send the event so the shred will stay alive forever. Very simple, very light on the CPU.
Also; it looks intuitively sensible, I think.
_________________
Kassen |
|
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
| Posted: Tue Feb 20, 2007 2:06 pm Post subject:
Re: Warning: don't forget to advance time in the main loop |
|
|
| Kassen wrote: | I'd also like to go back a bit and look at *why* You'd like to have a "main loop" that consists of only;
I'm going to asume that this is to keep shreds you sporked so far alive, right?
Next time you coud try this;
| Code: |
Event the_end;
the_end => now; |
This will define a event, then wait for it to happen. Then we'll simply never send the event so the shred will stay alive forever. Very simple, very light on the CPU.
Also; it looks intuitively sensible, I think. |
Ah!
That's a pretty solution, thanks!
To my defence I'd like to point out that there are examples delivered with chuck that end with stuff like this:
| Code: | // infinite time loop - children shreds leave with parent shred
while( true )
1::second => now;
|
This works of course, but add a lump of code, figure out that you want to move it to something that you can spork, delete it along with the 1::second => now;, and you have yourself a frozen computer.  Perhaps Kassen's solution could be transferred to the chuck examples (one is shred/spork.ck)? 
Anyway, I won't be going done that alley again (and hopefully no one else).
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Feb 20, 2007 2:48 pm Post subject:
Re: Warning: don't forget to advance time in the main loop |
|
|
| Antimon wrote: |
To my defence I'd like to point out that.... |
There is realy no need for defences! We're alll learning, Chuck is great for making loads and loads of mistakes realy fast, then learning from them and getting a chance to make new ones.
We like this; it's good.
| Quote: |
...there are examples delivered with chuck that end with stuff like this:
| Code: | // infinite time loop - children shreds leave with parent shred
while( true )
1::second => now;
|
This works of course, but add a lump of code, figure out that you want to move it to something that you can spork, delete it along with the 1::second => now;, and you have yourself a frozen computer. Perhaps Kassen's solution could be transferred to the chuck examples (one is shred/spork.ck)?
|
That's true. What's going on there is that those examples demonstrate you can have several loops going on next to eachother in paralel. This concept is a bit confusing to people that are used to languages where you don't have that.
It might be better (if we need some sort of change) to replace those examples with a loop at the end that does something like this;
| Code: | int counter;
while(true){
counter++;
<<<counter>>;
1::second => now;
}
|
This would make it more clear that after sporking a function that does it's own thing you can still have a loop that does something different and which runs at a different rate.
That last bit is important; if both loops would run at the same rate they could be re-written as a single loop.
My own little trick here *only* keeps a shred alive and nothing more. In most cases it would be better to simply end the file with a real main loop and save yourself a shred. On some occasions my trick is usefull, for example to keep some definitions allive which might be shared by other shreds.
| Quote: |
Anyway, I won't be going done that alley again (and hopefully no one else).
|
You might do it again by accident. If you use a variable rate to advance time by (this can give nice modulations) then you need to make very sure that variable won't ever become zero. This can be hard at times and anyone could stuble into that by accident.
_________________
Kassen |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Tue Feb 20, 2007 3:57 pm Post subject:
|
|
|
This problem has plagues us for some time now. I went back in the code and made the following changes:
1. OS X watchdog enabled by default. If a freeze loop is encountered, the watchdog should observe that real-time audio has been blown to smitherines, and will, after a few seconds, lower the priority of the VM thread, allowing you to kill chuck, and regain control of your computer.
2. Windows watchdog fixed and enabled. Works the same way. I also lowered the priority of the VM thread to start with, which will prevent the freeze but may impact real-time robustness. We'll go through a beta testing phase to figure out how much it matters. You can always manually change the priority using the --level<N> flag. The executable should be compiled under Visual C++ (and not cygwin) and will work under command prompt and cygwin.
3. Linux is as before. Anyone have freeze problems here?
This should greatly alleviate the chuck empty loop syndrome...
I hope this helps, eventually!
code in CVS, and will be in 1.2.0.8. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Feb 20, 2007 5:34 pm Post subject:
|
|
|
I'm not so sure I agree with lowering the Windows priority to begin with.
I have seen my share of ChucK crashes, freezes and meltdowns and it's been hard to kill it at times but I never had to do a hard reset.
I do have to mention that my Windows install is severely stripped, to the point of disableing the network-adapter and it's drivers and so on. When you also have the usual fire-wall and virus scanning that Windows needs so badly on regular systems it might be a different affair.
Getting access to a lot of the cpu's time is a good thing, it does conflict with these freezes but in the long term I'd like something more clever then this plan which would also have down-sides in regular usage. After all; these freezes aren't very common and after a program freezes like this it would hopefully be edited to make that a thing of the past.
That being said; I'm not yet sure what this "clever" solution might be....
_________________
Kassen |
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004
Posts: 24389
Location: The Netherlands, Enschede
Audio files: 296
G2 patch files: 320
|
| Posted: Tue Feb 20, 2007 5:42 pm Post subject:
|
|
|
| Kassen wrote: | | That being said; I'm not yet sure what this "clever" solution might be.... |
Maybe two modes ? One for debugging/development and one for performance.
_________________
Jan
also .. could someone please turn down the thermostat a bit.
 |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Feb 20, 2007 5:47 pm Post subject:
|
|
|
To set that flag I'd need to buy Visual Studio, right? This is now free (beer), I think?
_________________
Kassen |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Feb 20, 2007 5:49 pm Post subject:
|
|
|
Sounds good to me, Jan!
_________________
Kassen |
|
|
Back to top
|
|
|
elektro80
Site Admin
Joined: Mar 25, 2003
Posts: 21959
Location: Norway
Audio files: 14
|
| Posted: Tue Feb 20, 2007 5:50 pm Post subject:
|
|
|
Free beer? 
WHERE????
_________________
A Charity Pantomime in aid of Paranoid Schizophrenics descended into chaos yesterday when someone shouted, "He's behind you!"
MySpace
SoundCloud
Flickr |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Feb 20, 2007 6:04 pm Post subject:
|
|
|
| elektro80 wrote: | Free beer?
WHERE???? |
Free *as in beer*. There are other sorts of freedom as well, you should try them, I hear they run very well on Mac's.
:-p
_________________
Kassen |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Tue Feb 20, 2007 8:19 pm Post subject:
|
|
|
| Kassen wrote: | I'm not so sure I agree with lowering the Windows priority to begin with.
I have seen my share of ChucK crashes, freezes and meltdowns and it's been hard to kill it at times but I never had to do a hard reset. |
same here. though in the limited testing I've done, lowering the priority from "realtime critical" to "highest" on Windows appear to have similar robustness, including with the cpu is hard at work. The difference in ease-to-kill when a misbehaving shred runs is pretty significant. So, it might be useful to go through the beta testing phase. In any case, the watchdog now does a decent job of returning "realtime critcial" to more usable state, after a few seconds, so we might not need to lower the priority. On the other hand, never freezing on windows is actually a nice thing especially for new chuckists...
| Quote: | | Getting access to a lot of the cpu's time is a good thing, it does conflict with these freezes but in the long term I'd like something more clever then this plan which would also have down-sides in regular usage. After all; these freezes aren't very common and after a program freezes like this it would hopefully be edited to make that a thing of the past. |
good points..
| Quote: | | That being said; I'm not yet sure what this "clever" solution might be.... |
me neither... |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Tue Feb 20, 2007 8:21 pm Post subject:
|
|
|
| Kassen wrote: | | To set that flag I'd need to buy Visual Studio, right? This is now free (beer), I think? |
actually, you can always set the priority level from the command line chuck directly. On windows --level15 is the critical I think, --level2 is highest, --level0 is normal, --level-2 is lowest.
beer good... |
|
|
Back to top
|
|
|
jksuperstar
Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18
|
| Posted: Tue Feb 20, 2007 8:43 pm Post subject:
|
|
|
I guess the best fix is using a linux live cd if you've got one 
Running things at critical can also be dangerous to stability. This supposedly means a thread can preempt system tasks such as timer updates and whatnot. I don't know if chuck depends on windows OS timers, but it can also bite you if you are reading/writing with a hard disk (so you're samples don't get saved in time, buffers overflow, and data is lost)
Choosing the *right* level of priority is always the best answer. Figuring out what's right is not easy, and you're right Ge, a beta is a good idea.
I knew a band in Massachusetts years ago that was called Free Beer. You can guess what their flyers for gigs implied..."Free Beer at such&such Tavern!" |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Feb 20, 2007 9:48 pm Post subject:
|
|
|
A Linux Live cd would be cool if it weren't for those EMU people that don't see any need to suport Linux and me having a 1616m that's wonderfull aside from that one pesky issue.
About free beer; I once went to a party that was advertised as having "free beer and drunk models". This was true, very quickly the models became drunk on the free beer. Sadly the party was in a trendy shoe-store which didn't help make me comfortable since I wear big boots or go barefoot. It was also in New York meaning no smoking inside. Then my lack of sleep, not being able to find a way to sensibly talk with NY models and the free beer made it all quit sureal.
Not nearly as good as *cheap* beer parties in my own experience but at least it was all it promissed to be.
Since when, BTW, can ChucK releases be non-beta? I'm shocked!
_________________
Kassen |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Tue Feb 20, 2007 10:14 pm Post subject:
|
|
|
| jksuperstar wrote: | | Running things at critical can also be dangerous to stability. This supposedly means a thread can preempt system tasks such as timer updates and whatnot. I don't know if chuck depends on windows OS timers, but it can also bite you if you are reading/writing with a hard disk (so you're samples don't get saved in time, buffers overflow, and data is lost) |
I think in general, running chuck at all is dangerous to stability. Though with chuck, no matter how bad things get (short of crashing - another story), the audio is guaranteed to be precise to the sample, even if real-time cannot keep up. Files will still write correctly. Of course a misbehaving loop can halt things in their tracks, since that's also consistent with the chuck timing semantics.
We will continue find the good balance with things! |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Tue Feb 20, 2007 10:19 pm Post subject:
|
|
|
| Kassen wrote: | | About free beer; I once went to a party that was advertised as having "free beer and drunk models". This was true, very quickly the models became drunk on the free beer. Sadly the party was in a trendy shoe-store which didn't help make me comfortable since I wear big boots or go barefoot. It was also in New York meaning no smoking inside. Then my lack of sleep, not being able to find a way to sensibly talk with NY models and the free beer made it all quit sureal. |
another insipirational free beer story! how excellent.
| Quote: | | Since when, BTW, can ChucK releases be non-beta? I'm shocked! |
Great point. By "beta", I mean pre-alpha. Or maybe negative beta... |
|
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
| Posted: Wed Feb 21, 2007 12:52 am Post subject:
|
|
|
I forgot to mention some details concerning the lockup that may be interesting. I'm using the precompiled Windows binary (not compiled with cygwin).
I was running chuck in a cygwin xterm (using cygwin's XWindows). When chuck locked up, I experienced that I could move the mouse pointer around occasionally, but not do anything. I tried banging ctrl-c many times, but nothing happened. ctrl-alt-delete didn't do anything either. After maybe ten minutes I ran out of patience (nothing that critical on that particular PC anyway), so i hit reset.
Maybe cygwin's processing manager, and the fact that I was using X-windows, made it a little bit more difficult to do whatever I needed to do to kill the process? If I had run on an ordinary DOS prompt I would have been able to kill it?
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
|
moudi
Joined: Oct 07, 2006
Posts: 63
Location: Bern Switzerland
|
| Posted: Wed Feb 21, 2007 5:08 am Post subject:
|
|
|
hi all
| Antimon wrote: | | My computer completely froze and the restart button was called for. /Stefan |
interesting that in miniAudicle i was always able to kill it within the taskmanager... i never had to reboot.
regards
/moudi |
|
|
Back to top
|
|
|
jksuperstar
Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18
|
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Wed Feb 21, 2007 9:31 am Post subject:
|
|
|
| Antimon wrote: |
If I had run on an ordinary DOS prompt I would have been able to kill it?
/Stefan |
No promisess but in my own case I have always been able to kill a dos-box.
There might be other factors (or you could stick to cygwin and remember to advance time, that would also help  ). It's totally valid to have loops that don't advance time; I often use a few "for" loops at the start of my files to help set stuff up before any actual work is done or do stuff like copy one array to another while it runs. Just make sure those will always terminate somewhere and try to avoid realy big/heavy ones that will run while there is audio going.
Re; "negative beta"; We could call a alpha branch "commet" because it represents a bright hope as well as great crash potential! (we need a contest or something to make up a good name for the mini-audicle too!).
Re 1626m; That's great news, JKS!!!!! I think I'll have to go multi-boot on my laptop then. Eventually my own sequencer will obviously make Ableton and hence Win obsolete <g>. Do I see corectly in this table that that would exclude MIDI?
_________________
Kassen |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Wed Feb 21, 2007 3:10 pm Post subject:
|
|
|
| Antimon wrote: | I forgot to mention some details concerning the lockup that may be interesting. I'm using the precompiled Windows binary (not compiled with cygwin).
I was running chuck in a cygwin xterm (using cygwin's XWindows). When chuck locked up, I experienced that I could move the mouse pointer around occasionally, but not do anything. I tried banging ctrl-c many times, but nothing happened. ctrl-alt-delete didn't do anything either. |
I was able to reproduce very similar behavior using the win32 binary, a more recent build, and running in cygwin. the freeze slowed things down and allowed occassional mouse movement. With the new changes I added:
1. the watchdog kicks in and returns the system to a smooth running state within a few seconds. you can then easily hit ctrl-c to stop chuck.
2. if the priority is lowered to begin with, then the watchdog is not necessary.
So at this point, we should figure out through negative beta testing, if #2 is a good idea overall or not. The priority would be lowered from "CRITICAL" to "HIGHEST" in windows by default, and can also be set from the command line.
Thanks for the additional info. Don't know if the solutions are good ones, but at least we are on the right track I think. |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
