-
Notifications
You must be signed in to change notification settings - Fork 54
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
SSR crashes when TCP is disconnected #130
Comments
Possibly related information; if the TCP connection from the VST goes idle (ie: the VST's GUI is closed instead of minimised, and the VST stops checking the socket) then SSR starts leaking memory, which eventually consumes the entire available RAM and brings down the host system if the connection is left idle for too long. |
Sounds like #47 ? |
The first problem sounds like a bug in the network interface. Sadly, I currently don't have time to look into that. I hope somebody else can hunt down the bug! The second problem is most likely unrelated to the first. The problem is that the SSR just keeps sending network messages, whether somebody is reading them or not. That's not really a bug, but it is annoying nevertheless. One work-around would be to force the client to always read all data from the socket, another work-around is to remove a few lines from the SSR source code where the network interface tries to send messages that are not needed. This annoying behavior of the network interface was part of the reason why I created #127, which allows network clients to specify which data they want to receive, if any. I personally will not update the current network interface to support this new feature, but I've already implemented it in our new WebSocket-based network interface: #131. This doesn't really help you though, because the VST plugin of course uses the old network interface. |
Using the Windows SSR fork :: https://github.com/chris-hld/ssr
Using the Windows SSRemoteVST fork :: https://github.com/Taita-Yam/SSRemoteVST
I can successfully connect at least 14 instances of the Windows vst automation plugin in WFS mode, and it remains reliable ad infinitum as long as I do not disconnect the VST's TCP connection to the SSR. When I disconnect a few of the VST's or close the host DAW, the multiple disconnection events reliably cause SSR to crash with the error ::
"
terminate called after throwing an instance of 'std::bad_weak_ptr'
what(): bad_weak_ptr
"
This crash can also be caused by repeatedly connecting and disconnecting the Android app.
The text was updated successfully, but these errors were encountered: