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