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

Limiter No.6 causes deadlock when changing latency mode while processing #4325

Closed
PhysSong opened this issue Apr 26, 2018 · 1 comment · Fixed by #4540
Closed

Limiter No.6 causes deadlock when changing latency mode while processing #4325

PhysSong opened this issue Apr 26, 2018 · 1 comment · Fixed by #4540
Assignees

Comments

@PhysSong
Copy link
Member

To reproduce:

  1. Load Limiter No.6 on master channel
  2. Press "Fix. latency" while playing audio

Here's the relevant part of backtrace for RemoteVstPlugin.exe.so:

Thread 3 (Thread 0x2393b40 (LWP 14783)):
#0  0xf7fd5059 in __kernel_vsyscall ()
#1  0xf7dda5c2 in __lll_lock_wait () from /lib/i386-linux-gnu/libpthread.so.0
#2  0xf7dd2b7c in pthread_mutex_lock ()
   from /lib/i386-linux-gnu/libpthread.so.0
#3  0x7fb0dffd in RemoteVstPlugin::lockShm() ()
   from /home/hjsong/.wine/dosdevices/z:/usr/local/lib/lmms/RemoteVstPlugin.exe.so
#4  0x7fb0ba8c in RemoteVstPlugin::updateInOutCount() ()
   from /home/hjsong/.wine/dosdevices/z:/usr/local/lib/lmms/RemoteVstPlugin.exe.so
#5  0x7fb0c1b0 in RemoteVstPlugin::hostCallback(AEffect*, int, int, int, void*, float) ()
   from /home/hjsong/.wine/dosdevices/z:/usr/local/lib/lmms/RemoteVstPlugin.exe.so
#6  0x1001b6ab in ?? ()
#7  0x10017ee3 in ?? ()
#8  0x1001a63d in ?? ()
#9  0x7fb07946 in RemotePluginClient::doProcessing() ()

The problem is the callback tries to lock m_shmLock but it's already locked by doProcessing. I don't know which solution will be the best, but what I think is: make m_shmLock to a recursive mutex.

@DomClark Any ideas/suggestions?

@DomClark
Copy link
Member

I don't think making m_shmLock recursive is a good solution in general - the purpose of the mutex is to prevent m_inputs, m_outputs and the shared memory from being deleted during a call to m_plugin->processReplacing. It might work in this particular case, but for other plugins it may well result in use-after-free crashes within the plugin.
In this case, the plugin is using audioMasterIOChanged to announce a latency change, not a change in the number of inputs and outputs. We can easily check if the IO count hasn't changed (inputCount() == RemotePluginClient::inputCount() && outputCount() == RemotePluginClient::outputCount()) and return immediately without taking the lock in this case. A more general solution might be trickier. I'll work on a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants