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

Questions
1

Hello,

I have a problem with SuperCollider 3.14.0-dev (build form source) on a Machine running Ubuntu studio 22.04.5 LTS.

I have the same set up from several years and I never had any trouble until about 4 months.
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 a week 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.
All I can say is that it happens only on this machine. Same setup (code, plug ins, quarks…) on another machine works fine.

I tried a lot of things to try to make the error reproducible but I didn’t succeed.

I tried to rebuild SuperCollider in debug mode and attach gdb to it by following these steps:

set server options

s.options.asOptionsString // to get the server command line parameters

Then, in a terminal:

gdb --args scsynth (and paste the command line args here)

at gdb prompt:

run

Then, back in SC:

Server.default = s = Server.remote(\debug, NetAddr("127.0.0.1", 57110), s.options);

and

s.connectSharedMemory;

It has now been several weeks that I attach SuperCollider to gdb for each use while waiting for the problem to occur.
Yesterday I encountered this interpreter crash problem several times but nothing happens in gdb, this is the output of gdb:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6d59640 (LWP 5997)]
no more csLADSPA plugins
Found 353 LADSPA plugins
[New Thread 0x7fffd8fff640 (LWP 5998)]
[New Thread 0x7fff861e7640 (LWP 5999)]
[New Thread 0x7ffff2394640 (LWP 6000)]
[New Thread 0x7ffff1f85640 (LWP 6001)]
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
[New Thread 0x7ffff1f04640 (LWP 6002)]
[New Thread 0x7fff859e6640 (LWP 6003)]
SuperCollider 3 server ready.
MiClouds > numAudioIns: 2
JackDriver: max output latency 23.2 ms

I don’t know what to do from here, if anyone has a suggestion, it would be welcome

2

It seems you attached to scsynth instead of sclang?

3

I have just compiled 3.15.0-dev on a fresh version of Ubuntu 24.04.3, and I got the same result:

compiling class library...
Interpreter has quit. [Exit code: 11]
4

Thank you
I don’t know how to attach gdb to sclang.
Is it just ?

gdb --args sclang

and at gdb prompt:

run

?
Do I need to do the following ?
back in SC:

Server.default = s = Server.remote(\debug, NetAddr("127.0.0.1", 57110), s.options);

and

s.connectSharedMemory;

?

5

I don’t have experience with gdb, I only use lldb. But you need a debug build of sclang and then attach a debugger to it - you do not need any additional config of the server server since the interpreter is completely independent of the server.

6

The catch is that you need the IDE to start sclang. (When debugging the server or plugins, you can run the server process from gdb and let sclang connect to it. But that doesn’t work for the language – there’s no way to have the IDE connect to a command-line sclang instance.)

It “should” be:

  • Launch IDE.
  • In a terminal, ps x | grep sclang and find the pid.
  • gdb sclang xxxx substituting the pid
  • continue (within gdb)

… though I’m not 100% sure. I can give it a try a little bit later.

hjh

7

Thank you
I think I figured it out (not tested yet).
You have two options:
1- attach gdb to sclang:

gdb --args sclang file.scd

2- attach to running process:

gdb -p <process id>

and to get the process id in the IDE, I assumed you can type:

thisProcess.pid

Again I didn’t test these so I’m not sure.
I’ll test tomorow.

I have build SuperCollider with this:

-DCMAKE_BUILD_TYPE=RelWithDebInfo

Do I have a debug build of sclang in that condition ?

8

I posted my answer before reading yours sorry.
I’ll try that tomorow thank you for your help.

9

I got one thing wrong – at least on my (Ubuntu Studio) machine, attaching to a running process requires superuser privileges.

So it’s sudo gdb sclang xxx (substituting pid), then continue in gdb.

I confirmed that code blocks run from the IDE function normally, and exiting SC does show up in the debugger as well.

hjh

10

I see your running 3.14-dev rather than the new 3.14.1, any reason for this? The dev builds should always be considered unstable.

11

I think @kesey means the SC 3.15.0‑dev build.
On Ubuntu, the official release distributed via the App Centre is still 3.13.0.
To use the most recent version, users should build SuperCollider from source.

12

Thank you very much for your help

13

I’m on 3.14.0-dev since several years and when I tried to change to 3.13 for example some of my graph sounds differents that’s why I’d like to stick to this build

14

No, when I wrote 3.14.0-dev, I meant 3.14.0-dev.
It’s a bit strange to assume that the op doesn’t know what he is writing

15

I have build SuperCollider with this:

-DCMAKE_BUILD_TYPE=RelWithDebInfo

Can you confirm that I have a debug build of sclang in that condition please ?

16

The difference between Release and RelWithDebInfo is that RelWithDebInfo includes debugging symbols and Release does not. (Both build types have full compiler optimizations.)

The difference between RelWithDebInfo and Debug is that Debug switches off the compiler optimizations.

Some bugs occur only with compiler optimizations, so I think RelWithDebInfo is better than Debug to start troubleshooting.

(dscheiba was probably busy btw, I guess.)

hjh

17

Thank you and some more characters

18

Ah in this case do you have the exact commit you are using? When we talk about a dev build, we usually mean 3.14.1-dev (or whatever the current version number is)… which will become 3.15 some time next year, as our development branch is the active branch and the specific versions more like snapshots in history. Which is why I imagine @prko assumed you had a typo!

Sorry to be nit-picking about versions but there have been a lot of changes with the apple builds and scsynth stuff recently so it’s possible this has been fixed already, or at least known.

Now this is an issue we try really hard to avoid, and if you had the time and capacity, would all really appreciate a dedicated issue as it really hard for us to test for all the possibilities! There was some bug fixes to initialisation that might have affected this (I’m not really involved with the server so don’t know all the details here).

1 Like
19

Sorry, this was due to my lack of experience.

  1. Before writing my first answer to this thread, I built from source, and the version was 3.15.0‑dev. I know that users can change the version, but I have personally never done so.
  2. I also make a lot of typos.

I apologise once again for my mistaken assumption.

20

Hello,

I don’t know how to get the exact commit I’m using.
If someone can help me with that, it’ll be welcome.

But like I said in my previous post

I think I built this version of SuperCollider in march 2023. Don’t know if it’s relevant for you.
I can assure you that I’m not running 3.14.1-dev but 3.14.0-dev (built in march 2023 and no update since then)