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

SSR crashes when TCP is disconnected #130

Open
Taita-Yam opened this issue Jan 27, 2019 · 3 comments
Open

SSR crashes when TCP is disconnected #130

Taita-Yam opened this issue Jan 27, 2019 · 3 comments

Comments

@Taita-Yam
Copy link

Taita-Yam commented Jan 27, 2019

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.

@Taita-Yam
Copy link
Author

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.

@chohner
Copy link
Contributor

chohner commented Jan 27, 2019

Sounds like #47 ?

@mgeier
Copy link
Member

mgeier commented Jan 29, 2019

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.

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

3 participants