[chuck-users] 147th shred removed...segmentation fault? (Ryan Supak)

[Michael Heuer]

Interesting find, even this simple example blows for me

dmxBug.ck:

fun void blink()
{
  while (true)
  {
    50::ms => now;
  }
}

Shred shred;
spork ~ blink() @=> shred;

0 => int count;

while (true)
{
  200::ms => now;
  shred.id() => Machine.remove;
  spork ~ blink() @=> shred;
  <<<"count", count>>>;
}

$ chuck --silent examples/dmxBug.ck
...
[chuck](VM): removing shred: 144 (spork~exp)...
count 0
[chuck](VM): removing shred: 145 (spork~exp)...
count 0
[chuck](VM): removing shred: 146 (spork~exp)...
Segmentation fault: 11

   michael


On Mon, Jun 23, 2014 at 5:17 PM, Ryan Supak <ryansupak at gmail.com> wrote:
> Update: I eliminated everything I could from the Shreds that were being
> Sporked, and I still get the exact same error (at exactly 147 Shreds.)
>
> Here is what I shortened the Shreds to:
>
> fun void Blink()
> {
>     while( true )
>     {
>         50::ms => now;
>     }
> }
>
> fun void LFOMod()
> {
>     while( true )
>     {
>         50::ms => now;
>     }
> }
>
>
> On Mon, Jun 23, 2014 at 4:22 PM, Ryan Supak <ryansupak at gmail.com> wrote:
>>
>> Thanks for the thorough reply. I'm doing one safer, even than "voice
>> stealing": each Spork is, at most, reconfiguring a single global oscillator.
>>
>> Attached is the entire source. Lines 128-142 contain initialization code
>> that creates a Shred to make an LED blink by sending a MIDI message within a
>> time loop, and another Shred that sets the frequency of an LFO, polls it
>> every ten milliseconds, and sends some Serial output based on the LFO
>> position.
>>
>> Anytime that the parameters controlling the blinking rate and the LFO
>> rate/phase have occasion to change (when MIDI events come in to change
>> them), the "old" Shreds are Machine.Remove'd and they're recreated
>> immediately following. You can see this at lines 343 and 589.
>>
>> Notice that the LFOMod function and the Blink function aren't creating
>> anything new (with the exception of local arguments being instantiated), but
>> if you think those local arguments could be causing my problem I'll
>> eliminate them too.
>>
>> Please see the attached.
>> rs
>>
>>
>> On Mon, Jun 23, 2014 at 11:59 AM, Perry R Cook <prc at cs.princeton.edu>
>> wrote:
>>>
>>> I have lots of programs that spork hundreds or thousands
>>> of shreds without this error.  So, without seeing your
>>> code, my guesses (and questions) are as follows:
>>>
>>> Are you running this on a small memory architecture? Since
>>> you say headless, I'm guessing maybe Raspberry Pi?  It
>>> could be that you're running out of memory, so see next
>>> question.
>>>
>>> Does the shred that you're sporking declare new UGs or
>>> require memory to be allocated (arrays, lots of string
>>> manipulation, etc.)?  In general, this is a bad idea if you
>>> can avoid it.  ChucK does no garbage collection, which
>>> means that you need to be cautious about declaring memory.
>>>
>>> So even a shred as simple as:
>>>
>>> fun void mySine()  {
>>>     SinOsc s => dac;
>>>     Math.random2f(100,1000) => s.freq;
>>>     second => now;
>>>     s =< dac;
>>> }
>>>
>>> will eat up memory, because even though the SinOsc
>>> is unchucked and never computes again, the memory
>>> for that structure is still around.  We want, someday
>>> to make ChucK a proper garbage collecting language,
>>> but it's hard, especially for real-time systems.
>>>
>>> If this turns out to be your issue, then one way to
>>> handle this is to make a global pool of fixed
>>> resources and have your shred grab from that.
>>> Like classic "round robin voice stealing" in
>>> synthesizers:
>>>
>>> SinOsc s[100];
>>> 0 => int next2Use;
>>>
>>> fun void mySine() {
>>>     next2Use => int thisOne;
>>>     1 +=> next2Use;
>>>     if (next2Use > 99) 0 => next2Use;
>>>     s[thisOne] => dac;
>>>     Math.random2f(100,1000) => s[thisOne].freq;
>>>     second => now;
>>>     s[thisOne] =< dac;
>>> }
>>>
>>> // to test:
>>> while (1) {
>>>     Math.random2f(0.01,0.1) :: second => now;
>>>     spork ~ mySine();
>>> }
>>>
>>> I just fired up a few dozen of these running in
>>> parallel, VM showed 2600 total shreds running,
>>> no problem (and no clicks or dropouts!!).
>>>
>>> Hope this helps, if none of this applies, then you
>>> may have discovered a strange bug.  Source code please,
>>> and we can all scratch our heads on it.
>>>
>>>  Thanx!!  PRC
>>>
>>>
>>> Today's Topics:
>>>
>>>    1. 147th shred removed...segmentation fault? (Ryan Supak)
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>