search

SoundScapeRenderer / ssr

Main source code repository for the SoundScape Renderer
http://spatialaudio.net/ssr/
GNU General Public License v3.0
134 stars 53 forks source link

SSR crashes when TCP is disconnected #130

Open Taita-Yam opened 5 years ago

Taita-Yam commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Sounds like https://github.com/SoundScapeRenderer/ssr/issues/47 ?

mgeier commented 5 years ago

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.