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

[scsynth] Accessing allocated memory from RT pool using C++ style wrapper fails #4124

Closed
michaeldzjap opened this issue Oct 13, 2018 · 2 comments

Comments

@michaeldzjap
Copy link
Contributor

Environment

  • Your SuperCollider version: 3.9.3
  • Your operating system and version: macOS High Sierra 10.13.6

Steps to reproduce (for bugs)

It is necessary to build two example UGens to reproduce the problem. Source for this:
UGenTests.zip. After building the two UGens and moving the relevant files to the Extensions folder try the following 3 cases:

  1. This fails (see next section for error)
s.boot; s.scope;

{ Test.ar(WhiteNoise.ar(0.1) ! 2) }.play
  1. This works
s.boot; s.scope;

{ Test2.ar(WhiteNoise.ar(0.1) ! 2) }.play
  1. This also works (kind of...)
s.boot; s.scope;

{ Test2.ar(WhiteNoise.ar(0.1) ! 2) }.play

Now free the synth and try

{ Test.ar(WhiteNoise.ar(0.1) ! 2) }.play

Now this does work if you start the synth right away. If you wait for a minute or so it fails again (garbage collection of allocated memory???)

Error message (for bugs)

For the first case, the server quits unexpectedly posting this in the SC console:

RESULT = 0
server 'localhost' disconnected shared memory interface

Expected Behavior

I would expect, given that I've done the memory allocating and free'ing in the UGen code correctly, that the Test UGen should not crash the server when ran.

Current Behavior

Clearly something goes wrong with allocating memory using the C++ style wrapper. It could very well be that I am misunderstanding something and hence, the error is entirely my fault. However, I cannot figure out myself what I might have done wrong. As far as I can tell I have followed the appropriate steps translating the old C way of doing this to the new C++ way.

@sonoro1234
Copy link
Contributor

sonoro1234 commented Oct 13, 2018

may be that
https://github.com/supercollider/supercollider/blob/develop/include/plugin_interface/SC_PlugIn.hpp#L270

should be called at the end of constructor?
(Instead of next(1))

@michaeldzjap
Copy link
Contributor Author

Ah I see! Good catch. That indeed seems to be the problem: Looking at its definition, set_calc_function() doesn't only set the calculation function, it also computes the first sample using the specified function. Hence, if you do this as the very first thing in your constructor before defining / initialising your state variables then things will go wrong understandably. Replacing the next() call with set_calc_function() solved it.

So actually there are some errors in the example files:

This:
https://github.com/supercollider/example-plugins/blob/d0622ac6a4919bc7db134561d292d71337a9823d/02b-MySaw/MySaw2.cpp#L15
should not happen first, but last and
https://github.com/supercollider/example-plugins/blob/d0622ac6a4919bc7db134561d292d71337a9823d/02b-MySaw/MySaw2.cpp#L30
is redundant

Same for https://github.com/supercollider/example-plugins/blob/d0622ac6a4919bc7db134561d292d71337a9823d/01b-BoringMixer/BoringMixer.cpp#L17
that seems redundant as well.

Actually, there are already two open issues for this:
supercollider/example-plugins#9
supercollider/example-plugins#8

Will leave a comment there and this can be closed I guess. Thanks for your help @sonoro1234

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

2 participants