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

pausing multiple times with n_run can crash scsynth #5191

Open
Sciss opened this issue Oct 5, 2020 · 1 comment
Open

pausing multiple times with n_run can crash scsynth #5191

Sciss opened this issue Oct 5, 2020 · 1 comment
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: scsynth

Comments

@Sciss
Copy link
Contributor

Sciss commented Oct 5, 2020

Environment

  • SuperCollider version: 3.10.2, 3.10.4
  • Operating system: Linux

Steps to reproduce

s.waitForBoot { fork {
  s.sendBundle(nil,
		["/g_new", 1009, 0, 0],
		["/n_run", 1009, 0],
	);
  SynthDef("foo", {
    Out.ar(0, DC.ar(0.0))
	}).send(s);
	s.sync;
  s.sendBundle(nil,
		["/s_new", "foo", 1011, 1, 1009]
	);
	1.0.wait;
	"tada!".postln;
	s.sendBundle(nil,
		["/n_run", 1011, 0],
		["/n_run", 1011, 0], // this is needed. SO WEIRD
		["/n_run", 1011, 1],
		["/n_run", 1009, 1],
	);
}};

Expected vs. actual behavior

The above example crashes the server (when sending the last bundle after "tada"). It makes a difference whether the synth is "paused twice" or not. I.e. if the line "this is needed" is removed, scsynth no longer crashes. Seems quite a fundamental/severe bug to me. We tried to different versions and computer so far.

@Sciss Sciss added bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: scsynth labels Oct 5, 2020
@mossheim mossheim self-assigned this Oct 6, 2020
@mossheim
Copy link
Contributor

mossheim commented Oct 6, 2020

@Sciss i think this patch will fix it:

diff --git a/server/scsynth/SC_Node.cpp b/server/scsynth/SC_Node.cpp
index 92a6236a5..520f52af4 100644
--- a/server/scsynth/SC_Node.cpp
+++ b/server/scsynth/SC_Node.cpp
@@ -260,7 +260,9 @@ void Graph_NullFirstCalc(Graph* inGraph);
 void Node_SetRun(Node* inNode, int inRun) {
     if (inRun) {
-        if (inNode->mCalcFunc == &Node_NullCalc) {
+        if (inNode->mCalcFunc == &Node_NullCalc || inNode->mCalcFunc == (NodeCalcFunc)&Graph_NullFirstCalc) {
             if (inNode->mIsGroup) {
                 inNode->mCalcFunc = (NodeCalcFunc)&Group_Calc;
+            } else if (inNode->mCalcFunc == (NodeCalcFunc)&Graph_NullFirstCalc) {
+                inNode->mCalcFunc = (NodeCalcFunc)&Graph_FirstCalc;
             } else {
                 inNode->mCalcFunc = (NodeCalcFunc)&Graph_Calc;
@@ -270,5 +272,5 @@ void Node_SetRun(Node* inNode, int inRun) {
     } else {
         if (inNode->mCalcFunc != &Node_NullCalc) {
-            if (!inNode->mIsGroup && inNode->mCalcFunc == (NodeCalcFunc)&Graph_FirstCalc) {
+            if (!inNode->mIsGroup && (inNode->mCalcFunc == (NodeCalcFunc)&Graph_FirstCalc || inNode->mCalcFunc == (NodeCalcFunc)&Graph_NullFirstCalc)) {
                 inNode->mCalcFunc = (NodeCalcFunc)&Graph_NullFirstCalc;
             } else {

basically we need to keep better track of the 'first-calc'-ness of the node. there could be more bugs in this code, but it passes your test case. if i have more time to test this week i will submit a PR. thanks for the report!

@mossheim mossheim removed their assignment Apr 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: scsynth
Projects
None yet
Development

No branches or pull requests

2 participants