[chuck-dev] segmentation fault on function call

Michael Heuer heuermh at gmail.com
Mon Jan 28 18:22:15 EST 2013

Kassen <signal.automatique at gmail.com> wrote:
> On Mon, Jan 28, 2013 at 04:48:11PM -0600, Michael Heuer wrote:
>> Hello,
>> The following crashes ChucK
>> $ chuck --version
>> chuck version: (chimera)
>>    mac os x : intel : 64-bit
>>    http://chuck.cs.princeton.edu/
>>    http://chuck.stanford.edu/
>> funCrash.ck:
>> class Foo
>> {
>>     1.0 => float _f;
>>     fun float foo(float f)
>>     {
>>         f => _f;
>>         return _f;
>>     }
>> }
>> Foo f;
>> 42.0 => f.foo;
>> <<<"foo", f.foo>>>;
>> $ chuck funCrash.ck
>> Segmentation fault: 11
>> Both the write and read are necessary to make ChucK crash.
> This is odd. The "read", as you call it, should IMHO be a syntax error
> at best; you seem to mean to refer to f._f there, to read, Not the
> "foo" function which should really be called "foo()" and isn't
> overloaded to deal with 0 arguments. At best calling f.foo should give
> the memory address of the function.

Yes, odd.

That pattern is my best attempt to make classes/chugens/chubgraphs
look more UGen-ly, in that you can use value => foo notation and
f.foo(value) notation.  Typically in my use cases there are side
effects in the function call in addition to setting the value of the
field, so just doing value => f._f in the example above would not be

For example, this method sets a bunch of stuff


> It is a bug though, as your code should under no condition except for
> Machine.crash() crash the machine. Should, I said ;-). Some editions
> ago we seem to have run into what I suspect is a error handler bug;
> things that used to be plain errors now instead crash the whole vm.
> Not good as that makes livecoding in ChucK a bit too dangerous, IMHO.
> Anyway, I have no idea why the write would matter unless it is related
> to the unused return value of the function. I seem to remember
> somebody (Spencer?) commenting a long time ago how those would somehow
> end up on the stack, I thought that had been dealt with (as it should
> be, nowhere in the docs does anything imply you need to use return
> values and the stack is not something end-users should run into
> anyway).
> So; BUG, and a nice data-point that might help explain what is going
> so terribly wrong in the error handler (unless my gut-feeling is wrong
> and it might indicate something else). Congratulations on your catch.

Thanks.  If you're not breaking ChucK or blowing up a channel on your
mixer occasionally, you're not trying hard enough.  :)


More information about the chuck-dev mailing list