Hello all, I was recording a session (using /examples/basic/rec-auto.ck -s) and I recieved the following error about a quarter of the way through: _______ 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? b.) how can I avoid having it happen again? Thanks for chuck -- I am enjoying it very much! Greg Brown [University of Georgia]
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!
Ge, Thank you so much for your insight. I think your reply has given me some ideas of how to approach this. Currently I'm sporking shreds that read and output three sound buffers every 60 seconds or so. The .wav files are not huge, but if they are not all being discarded properly, they could easily be the source of the problem. So... since there are only 12 .wav files being read into buffers, perhaps (as I think you are suggesting) I can simply load them into a global variable (or a class variable within my object?) and then access them directly from within the subsequent shreds. (I'm not sure I got the terminology quite right...) Instead of 3 sndbufs/minute for 6.5 hours, only 12 total. Seems a little more efficient in any case. I'll let you know if I am still having problems after I get a chance to re-write and re-execute. Many thanks, Greg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gregory Brown Hugh Hodgson School of Music The University of Georgia 250 River Road – Office 361 Athens, Georgia 30602-7287 On Sep 17, 2006, at 4:19 PM, Ge Wang wrote:
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!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (3)
-
Ge Wang -
Greg Brown -
Gregory Brown