[chuck-users] crash question

Ge Wang gewang at CS.Princeton.EDU
Sun Sep 17 16:19:43 EDT 2006

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.


More information about the chuck-users mailing list