Seg fault when assigning to 2-dimensional array of references

[heuermh]

With a git clone of LiCK and

$ chuck --version

chuck version: 1.3.3.0 (chimera)
   mac os x : intel : 64-bit
   http://chuck.cs.princeton.edu/
   http://chuck.stanford.edu/

$ chuck --loop
[chuck](VM): sporking incoming shred: 1 (import.ck)...
...
[chuck](VM): sporking incoming shred: 288 (RubberBand.ck)...
"LiCK imported." : (string)
[chuck](VM): sporking incoming shred: 1 (syTuningsExample.ck)...
initializer... 0x105ff3b10 0x105b608c0 0x105b56ed0 
Segmentation fault: 11

in one terminal and

$ chuck + import.ck 
$ chuck + examples/syTuningsExample.ck

in another I get a seg fault.

The offending line in syTuningsExample.ck appears to be

tuning @=> _t[s][a];

https://github.com/heuermh/lick/blob/master/examples/syTuningsExample.ck

The code here is not so nice because I'm trying hard to work around not having static arrays of object references.

[aknuds1]

I can reproduce the segfault while running chuck in the terminal, however, in Xcode it doesn't crash (executes successfully AFAICT). I figured I'd try my hand at fixing this, but does anyone have a clue as to how I can debug the issue, i.e. get a stacktrace?

[spencersalazar]

@aknuds1 you might make sure Xcode is compiling running a 64-bit executable (or the same architecture as your terminal-based exe), as with memory access bugs (as this likely is) that will make a difference. Also make sure the command line version and Xcode project are from the exact same revision of the code.

Is there a single-file test case that will also cause the crash?

[aknuds1]

@spencersalazar I only use the executable built by Xcode, and it's built as 64-bit. Given that ChucK does not crash under Xcode, is there some other way to produce a stacktrace?

[heuermh]

Sorry, reproducing the original problem as described is a bit convoluted, I will look into producing a simpler test case.

What I would really like though are static arrays of object references. :)

[aknuds1]

I got a core dump, how can I use this to debug? I've only used gdb with coredumps on Linux, but that was ages ago.

According to the crash report in Console, the stacktrace looks like this:

Thread 6 Crashed:: com.apple.audio.IOThread.client
0   chuck                           0x0000000100056a8d Chuck_Instr_Assign_Object::execute(Chuck_VM*, Chuck_VM_Shred*) + 45
1   chuck                           0x000000010004c962 Chuck_VM::compute() + 338
2   chuck                           0x000000010004c6f8 Chuck_VM::run(long) + 72
3   chuck                           0x00000001000ba8df Digitalio::cb2(void*, void*, unsigned int, double, unsigned int, void*) + 399
4   chuck                           0x00000001000cb06d RtApiCore::callbackEvent(unsigned int, AudioBufferList const*, AudioBufferList const*) + 317
5   chuck                           0x00000001000ca2f7 callbackHandler(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 23
6   com.apple.audio.CoreAudio       0x00007fff8c724acb HALC_ProxyIOContext::IOWorkLoop() + 3667
7   com.apple.audio.CoreAudio       0x00007fff8c723bcd HALC_ProxyIOContext::IOThreadEntry(void*) + 97
8   com.apple.audio.CoreAudio       0x00007fff8c723a8d HALB_IOThread::Entry(void*) + 75
9   libsystem_pthread.dylib         0x00007fff87a12899 _pthread_body + 138
10  libsystem_pthread.dylib         0x00007fff87a1272a _pthread_start + 137
11  libsystem_pthread.dylib         0x00007fff87a16fc9 thread_start + 13

[gewang]

(slowly) cleaning house on time-honored tickets. FYI as of the latest 1.5.1.2, LiCK compiles and runs without error chuck import.ck Is this still an issue?

[heuermh]

I honestly don't remember if I found a workaround for this, will investigate