Hi Greg!
_______ chuck(366,0xa000ed98) malloc: *** vm_allocate(size=10604544) failed (error code=3) chuck(366,0xa000ed98) malloc: *** error: can't allocate region chuck(366,0xa000ed98) malloc: *** set a breakpoint in szone_error to debug terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Abort trap _______
This is a relatively large session (ca. 6.5 hours), and at the time the .wav file size was about 514MB (out of a projected 1.5-2.0GB). There was more than adequate room on the hard disk to recieve the file and the CPU was not busy with other tasks. The machine is running OS X.4.6 with Dual 1.25 GHz G4 and 512 MB RAM.
My questions: a.) what happened?
Oh no! This has all the signs of chuck running out of memory. The current effort to implement garbage collection is underway but not yet complete. Until then, there is only basic cleanup but in some places there are memory leaks that depending on the code could exhaust the process's heap after a while. It's possible in most cases to structure a program to eliminate or minimize leaks, but such "strategies" are not intended to be part of the required usage. Very sorry about this. We are definitely working hard on it.
b.) how can I avoid having it happen again?
One of the things that cause memory leaks is deallocating a shred when it leaves the VM. Actually, the shred itself is reclaimed correctly (we think), but the objects allocated inside the shred, even if they can and should be garbage collected, may not be. Needless to say, this is pretty serious and brain-damaged. One possible way to try to get around it would be allocate and reuse UGen's and other Objects (from a global class), connecting them and disconnecting them as needed, instead of adding and removing shreds which instantiate them. Same goes for instantiations in loops - best to do them more outside in scope if possible. I am not sure if this applies to your system. Can you give a brief description of your "steady state" operation of chuck? To be sure, this is chuck's fault, well my fault really for not finishing the garbage collector yet. But we are on it. We have delayed its release and it's difficult to commit to a date. So asap is for now the best estimate for a release with full garbage collection (the way it's supposed to be).
Thanks for chuck -- I am enjoying it very much!
Thank you! Simultaneously we gotta apologize for it. We think it's sucking less and less, but still got some major disaster areas and a ton of key features waiting to be realized. Best, Ge!