Seg fault when assigning to 2-dimensional array of references about chuck HOT 7 CLOSED

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?

from chuck.

@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?

from chuck.

@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?

from chuck.

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. :)

from chuck.

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

from chuck.

(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?

from chuck.

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

from chuck.