Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seg fault when assigning to 2-dimensional array of references #2

Closed
heuermh opened this issue Jun 13, 2014 · 7 comments
Closed

Seg fault when assigning to 2-dimensional array of references #2

heuermh opened this issue Jun 13, 2014 · 7 comments

Comments

@heuermh
Copy link
Contributor

heuermh commented Jun 13, 2014

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
Copy link

aknuds1 commented Jun 14, 2014

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
Copy link
Member

@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
Copy link

aknuds1 commented Jun 16, 2014

@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
Copy link
Contributor Author

heuermh commented Jun 16, 2014

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
Copy link

aknuds1 commented Jun 18, 2014

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

spencersalazar pushed a commit that referenced this issue Feb 25, 2017
Rephrase assertion failure as error message
dbadb added a commit to cannerycoders/chuck that referenced this issue Sep 30, 2021
nshaheed added a commit that referenced this issue Apr 16, 2022
dbadb added a commit to cannerycoders/chuck that referenced this issue Apr 22, 2022
spencersalazar pushed a commit that referenced this issue Jun 16, 2023
Rephrase assertion failure as error message
@gewang
Copy link
Member

gewang commented Aug 30, 2023

(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
Copy link
Contributor Author

heuermh commented Aug 30, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants