[chuck-dev] segmentation fault on function call

Kassen signal.automatique at gmail.com
Mon Jan 28 18:12:10 EST 2013

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.

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

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.


More information about the chuck-dev mailing list