Interpreter has crashed or stopped forcefully. [Exit code: 11]

kesey · January 24, 2026, 11:47pm

Thank you for your response.
I appreciate you trying to help me.

I will try to apply commit #6261 to the source code and rebuild.
If the problem persists, I will downgrade to 3.13,.
Are there any differences in GC between 3.13 and 3.14.0-dev (commit from 2023 (602ab7463))?
After that, if I still have interpreter problems, I will upgrade to 3.14.1.
Only the first option, namely finding the commit that solves my problem, could allow me to save my work because I am pretty sure that my graphs will sound different if I change versions (I experienced this on another machine).

I understand and after this extremely painful experience I will take great care not to build any more dev versions in the future.
I just wanted to point out that at the time I built SC (in 2023) there were no other solutions for Linux users outside of building which by default pointed to the dev branch.
I don’t know if that’s still the case, or if there is a reason that would explain this choice that I overlooked but maybe changing the branch by default during build could avoid this kind of problems for other users?

jordan · January 25, 2026, 8:45am

This is potentially a better problem to have, whereas hunting through the git history will be hard.

We try very hard to keep people’s work sounding the same between versions and the are far more people actively working on the ugen part of the code so it’s more likely we will be able to help.

I don’t think so, but it is a fragile system so other changes might affect it.

jordan · January 25, 2026, 7:55pm

This is a serious issue if this happens regularly. @jamshark70 in another thread you very recently recommend someone build SC and sc3plugins from source, do you know if that was the dev branch? If so, issues like this might/will come up again.

One idea I had was to post a big old message in the post window when running a developer build.

Spacechild1 · January 25, 2026, 8:01pm

Ouch! Having an unstable branch as the default branch is indeed quite dangerous. We should consider switching the default branch to main or add a prominent warning the README.

dscheiba · January 25, 2026, 10:02pm

we already have a section for this in the build linux readme → supercollider/README_LINUX.md at develop · supercollider/supercollider · GitHub

Spacechild1 · January 25, 2026, 10:42pm

Cool! We should just add a prominent warning there. (The README only explains how you would clone a particular branch instead of the default branch but it doesn’t really say why you can’t just use the default branch.)

jamshark70 · January 26, 2026, 5:27am

I think we should change this. Active devs know which branch they want to use. First-time builders should be able to assume that what they’ve checked out is a stable branch.

hjh

jordan · January 26, 2026, 11:48am

This will need some one with the correct gh permissions (not me).

dscheiba · January 26, 2026, 12:50pm

Lets not change the default branch - this would affect what branch is displayed when visiting the GH repo, which would maybe give a false sense of stalling development since we only push commits there every few months at best.
Additionally, all PRs would also target main as default branch from there on which we do not want and could lead to some trouble if an oversight happens here.
I think if people want to build SC themselves they should be somehow familiar with git or be guided by the README as this is the easiest part of the whole build process. And also most projects default to the develop branch.

Instead of changing the default branch we should document it and probably provide AppImage/FlatPak as an alternative for linux users

Spacechild1 · January 26, 2026, 3:56pm

which would maybe give a false sense of stalling development since we only push commits there every few months at best.

Well, you cannot expect a branch to be stable and have commits from the last few days. The fact is that many people expect the default branch to be stable. But of course that’s not the case for every project. (In Pd, the master branch is very much unstable and often outright broken )

I think if people want to build SC themselves they should be somehow familiar with git or be guided by the README as this is the easiest part of the whole build process.

One could also argue that a SC developer should be familiar enough with git/GitHub to target the correct branch or be guided by the README, probably more so than people who just want to build from source.

And also most projects default to the develop branch.

Is this the case? My impression has been the opposite. For example, in git-flow the default branch is main/master.

All that being said, I don’t have a strong opinion because I see the upsides and downsides of both approaches.

Xon · January 26, 2026, 6:31pm

Hello,

I do not know if it a known issue ?
But, by opening latest downloaded development version on MacOS 15.7.3, I have a crash :

Starting interpreter with “/private/var/folders/b6/tq4hd3g56y79nyh23px1knqm0000gn/T/AppTranslocation/05190220-C971-40B2-8787-AD47AE7CBF39/d/SuperCollider.app/Contents/Resources/…/MacOS/sclang -l /Users/xon/Library/Application Support/SuperCollider/sclang_conf.yaml -i scqt” in “”
compiling class library…
Interpreter has crashed or stopped forcefully. [Exit code: 11]

Everything works well on SC 3.14.1.

Christophe

kesey · April 14, 2026, 5:53pm

Hello,

4 months after I’m still in the same nightmare.
I’ve tried several patches:#6261, #7332 with no success.

I downgrade to 3.13.1, same issue (but my SynthDefs sound as they should).
I upgraded to 3.14.1 but as expected, I loose my work in this case cause my SynthDefs doesn’t sound the same (for example Fold.ar has changed between 3.13.1 and 3.14.1, it’s just one example, I have dozen of SynthDefs that sound very different).
So I didn’t keep this version and I actually downgrade to 3.13.1 again.

Is the issue could be related to something wrong in my code ?
I’ve experienced the issue when I started using Grainutils and after doing some minor modifications on this class:

Could it be related ?
Any help is much appreciated

kesey · April 14, 2026, 7:03pm

To sum up:

SuperCollider 3.13.1, Ubuntu studio 22.04.5 LTS.
From time to time the interpreter crash with this message:
Interpreter has crashed or stopped forcefully. [Exit code: 11]

it can happen anytime, I can’t isolate a piece of code to reproduce it unfortunately.
I can play with a piece of code without any trouble for weeks and one day suddenly, with the same code, the interpreter crash (not necessarily when I execute code, it can happen during the sound play at a moment when I don’t touch the keyboard).

it can happen several times in a row then no longer reproduce for several days/weeks.

After 6 months, I still not able to reproduce the problem with a piece of code, it looks totally random.

The output of gdb attach to sclang:

Thread 1 "sclang" received signal SIGSEGV, Segmentation fault.
PyrGC::DLInsertAfter (obj=0x557c0c48d900, after=0x557bfa1891c0, this=0x557bfa187440) at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/GC.h:219
219         after->next->prev = obj;
(gdb) where
#0  PyrGC::DLInsertAfter (obj=0x557c0c48d900, after=0x557bfa1891c0,
    this=0x557bfa187440)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/GC.h:219
#1  PyrGC::ToBlack (obj=0x557c0c48d900, this=0x557bfa187440)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/GC.h:243
#2  PyrGC::ScanOneObj (this=this@entry=0x557bfa187440)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/GC.cpp:545
#3  0x0000557bde101ce8 in PyrGC::Collect (this=0x557bfa187440)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/GC.cpp:676
#4  0x0000557bde102085 in PyrGC::Allocate (
    inRunCollection=<optimized out>, sizeclass=3, inNumBytes=112,
--Type <RET> for more, q to quit, c to continue without paging--
    this=0x557bfa187440)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/GC.h:307
#5  PyrGC::NewFrame (this=0x557bfa187440, inNumBytes=112,
    inFlags=inFlags@entry=0, inFormat=inFormat@entry=1,
    inAccount=<optimized out>)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/GC.cpp:393
#6  0x0000557bde1015ee in blockValue (g=0x557bde45f3a0 <gVMGlobals>,
    numArgsPushed=2)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangPrimSource/PyrPrimitive.cpp:939
#7  0x0000557bde12daac in doPrimitive (g=0x557bde45f3a0 <gVMGlobals>,
    meth=0x557bfca46500, numArgsPushed=<optimized out>)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangPrimSource/P--Type <RET> for more, q to quit, c to continue without paging--
yrPrimitive.cpp:3888
#8  0x0000557bde102a78 in Interpret (g=0x557bfa187440,
    g@entry=0x557bde45f3a0 <gVMGlobals>)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/PyrInterpreter3.cpp:3035
#9  0x0000557bde1bb3e8 in runInterpreter (g=0x557bde45f3a0 <gVMGlobals>,
    selector=<optimized out>, numArgsPushed=<optimized out>)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/PyrInterpreter3.cpp:127
#10 0x0000557bde1bfd4b in runLibrary (selector=<optimized out>)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/PyrLexer.cpp:2274
#11 0x0000557bde1f8a7f in SC_LanguageClient::tickLocked (
    this=this@entry=0x557bfa019f00, nextTime=nextTime@entry=0x7ffe47fd61b0)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/SC_La--Type <RET> for more, q to quit, c to continue without paging--
nguageClient.cpp:277
#12 0x0000557bde11db86 in QtCollider::LangClient::tick (
    this=0x557bfa019ef0)
    at /home/fabien/SuperCollider_source/supercollider/QtCollider/LanguageClient.cpp:92
#13 0x00007c04680e733f in QObject::event(QEvent*) ()
   from /lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007c0468f6c713 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007c04680b9e3a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007c04681123eb in QTimerInfoList::activateTimers() ()
   from /lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007c0468112d34 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007c046711bcbb in g_main_context_dispatch ()
--Type <RET> for more, q to quit, c to continue without paging--
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007c0467171258 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007c0467119363 in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007c04681130b8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007c04680b875b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007c04680c0cf4 in QCoreApplication::exec() ()
   from /lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x0000557bde11d9ed in non-virtual thunk to QtCollider::LangClient::commandLoop() ()
    at /home/fabien/SuperCollider_source/supercollider/QtCollider/LanguageClient.cpp:37
#25 0x0000557bde10ef40 in SC_TerminalClient::run (this=0x557bfa019f00,
--Type <RET> for more, q to quit, c to continue without paging--
    argc=<optimized out>, argv=<optimized out>)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/SC_TerminalClient.cpp:275
#26 0x0000557bde0fcd12 in main (argc=3, argv=0x7ffe47fd6798)
    at /home/fabien/SuperCollider_source/supercollider/lang/LangSource/cmdLineFuncs.cpp:27
(gdb) continue
Continuing.
Couldn't get registers: Aucun processus ayant ce numéro.
(gdb) [Thread 0x7c03d2ffd640 (LWP 2517) exited]
[Thread 0x7c03d37fe640 (LWP 2515) exited]
[Thread 0x7c03d3fff640 (LWP 2496) exited]
[Thread 0x7c03ce7f4640 (LWP 2495) exited]
[Thread 0x7c03cdff3640 (LWP 2378) exited]
[Thread 0x7c03cd7f2640 (LWP 2377) exited]
[Thread 0x7c03ccff1640 (LWP 2376) exited]
[Thread 0x7c03f0ff9640 (LWP 2360) exited]
[Thread 0x7c03f17fa640 (LWP 2359) exited]
[Thread 0x7c03f1ffb640 (LWP 2358) exited]
[Thread 0x7c03f27fc640 (LWP 2353) exited]
[Thread 0x7c03f2ffd640 (LWP 2352) exited]
[Thread 0x7c03f37fe640 (LWP 2351) exited]
[Thread 0x7c03f3fff640 (LWP 2350) exited]
[Thread 0x7c0418ff9640 (LWP 2349) exited]
[Thread 0x7c0419ffb640 (LWP 2348) exited]
[Thread 0x7c041b7fe640 (LWP 2344) exited]
[Thread 0x7c042cfff640 (LWP 2342) exited]
[Thread 0x7c042dbfe640 (LWP 2341) exited]
[Thread 0x7c042e3ff640 (LWP 2335) exited]
[Thread 0x7c042f7fe640 (LWP 2332) exited]
[Thread 0x7c043cfff640 (LWP 2330) exited]
[Thread 0x7c0448dfd640 (LWP 2329) exited]
[Thread 0x7c04495fe640 (LWP 2328) exited]
[Thread 0x7c0449dff640 (LWP 2327) exited]
[Thread 0x7c0450d66640 (LWP 2324) exited]
[Thread 0x7c04527ff640 (LWP 2319) exited]
[Thread 0x7c0453972640 (LWP 2316) exited]
[Thread 0x7c0454173640 (LWP 2315) exited]
[Thread 0x7c045439f400 (LWP 2291) exited]
[Thread 0x7c042ffff640 (LWP 2331) exited]
[New process 2291]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Thank you for your help

jordan · April 14, 2026, 7:17pm

Have you got any places where try or protect is called in a loop? If so, remove them.

Unfortunately the stack trace just reads as, woops, something broke! As that kind of error only happens when something else behaves badly.

kesey · April 14, 2026, 7:18pm

Thank you, I don’t use try neither protect in my code

jordan · April 14, 2026, 7:24pm

So 3.14.1 didn’t crash, but the synthdefs sounded different?

If you can isolate the synthdefs, reduce them down to a small size, it’s likely we can help adapt them.

Debugging interpreter bugs without a reproducers is basically impossible.

kesey · April 14, 2026, 7:28pm

I’m not sure 3.14.1 didn’t crash cause I didn’t use it for a long time due to the sound change