[chuck-users] crash question

[Gregory Brown]

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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20060917/67d4dbc1/attachment-0001.htm