VST freezes on Arch

[mateuszmnm]

Steps to reproduce:

• start LMMS
• drag VeSTige into main screen
• click on VeSTige's green folder icon
• select a .DLL VST plugin

Expected:

• loading plugin window appears
• plugin loads

Actual:

• loading plugin window appears
• one of the CPU cores goes 100%
• LMMS stops responding
• it stays like that forever

Screenshot: http://i.imgur.com/2f5YURI.png
Affected system: Arch 64 bit
LMMS versions: 1.1.1, 1.1.2, 1.1.3
Wine versions used: at least 4 different - 1.6.4. 1.7.22, 1.7.33, 1.7.38
Example VST: Synth1
More details: https://lmms.io/forum/viewtopic.php?f=7&t=1749

Some strace dump: https://gist.github.com/obszczymucha/161b9fb25ce0a48b6af3 (it goes like that forever)

[obszczymucha]

Doh, posted above on wrong account...

[obszczymucha]

I've profiled LMMS with Valgrind during reproducing the issue and here's the result:
https://www.dropbox.com/s/46p9g4bnknvs272/callgrind.out.2681?dl=0

I still don't know what to make out of this, but maybe someone else beats me to it.

[obszczymucha]

If that helps, I've managed to debug LMMS into a point where execution stops at: https://github.com/LMMS/lmms/blob/stable-1.1/plugins/vst_base/VstPlugin.cpp#L180

which is waitForInitDone()

I'm guessing LMMS waits for a signal from remote plugin and either doesn't get it or gets it but doesn't process it properly (or locked?).

Additionally I can see that wineserver process starts by doing 'ps aux'.

[badosu]

Great bug report @obszczymucha! 👍

I am also experiencing this bug.

[obszczymucha]

Bad news. We are stuck in the loop:
https://github.com/LMMS/lmms/blob/stable-1.1/include/RemotePlugin.h#L980

I've added:

printf("_busy_waiting: %d, messagesLeft(): %d\n", _busy_waiting, messagesLeft());

And it always outputs: _busy_waiting: 1, messagesLeft(): 0

[tresf]

Possible duplicate of #1567.
Related: #1097 #1736 #607

[badosu]

Reproduced on my machine as well, can't figure out why this happens.

[tresf]

@badosu does this happen with other VSTs (i.e. DSK musicbox?)

[badosu]

Yep, tested on lots of other VSTs. This is not a particular VST problem but with the messagery between wine and lmms as indicated above. At least, it's what it looks like/

[qnebra]

I have this same issue on lmms 1.1.3 from kxstudio in vivid.

[tresf]

@badosu is this a valid bug with our code, or a problem with the way these downstream packages are created?

[badosu]

@tresf I'd have to try a previous release to test this, I really don't know. Gonna take a look.

[mikesbytes]

I can also produce this issue on Arch using the provided packages. This also happens when I use the git version from AUR.

[Gnurou]

Same issue, also with Arch Linux 64 bit. Will try to investigate a bit further if I can find the time.

[Umcaruje]

Can any of you confirm this bug on Arch if you manually compile LMMS and not use the packages?

[obszczymucha]

I've built multiple versions from the source. Same problem. I'll try and build the latest 1.1.3 version and let you know the outcome.

[obszczymucha]

Just built 1.1.3 - the issue is still there.

[Gnurou]

Yes, this is from a source build. I have started looking at it, but could not rootcause it yet, excepted that it seems to be a miscommunication between the main process and RemoteVstPlugin. That part of the code is not particularly easy to comprehend to new eyes. Here is the top of the backtrace from the main process:

#0  0x00007ffff7bcdc1d in recvmsg () from /usr/lib/libpthread.so.0
#1  0x00007ffff082e917 in ?? () from /usr/lib/libxcb.so.1
#2  0x00007ffff082f188 in ?? () from /usr/lib/libxcb.so.1
#3  0x00007ffff28abdc8 in ?? () from /usr/lib/libX11.so.6
#4  0x00007ffff28abf2b in ?? () from /usr/lib/libX11.so.6
#5  0x00007ffff28ac23d in _XEventsQueued () from /usr/lib/libX11.so.6
#6  0x00007ffff289db10 in XEventsQueued () from /usr/lib/libX11.so.6
#7  0x00007ffff713bbf7 in ?? () from /usr/lib/libQtGui.so.4
#8  0x00007ffff3fcb1bd in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#9  0x00007ffff3fcbba8 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0x00007ffff3fcbd8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#11 0x00007ffff6952044 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#12 0x00007ffff713c156 in ?? () from /usr/lib/libQtGui.so.4
#13 0x00007ffff69255ce in QCoreApplication::processEvents(QFlags<QEventLoop::ProcessEventsFlag>, int) () from /usr/lib/libQtCore.so.4
#14 0x000000000053607e in RemotePluginBase::waitForMessage (this=0x1b6ae00, _wm=..., _busy_waiting=true) at /home/gnurou/Projects/lmms/lmms/include/RemotePlugin.h:954
#15 0x0000000000537fc7 in RemotePlugin::waitForInitDone (this=0x1b6ae00, _busyWaiting=true) at /home/gnurou/Projects/lmms/lmms/include/RemotePlugin.h:690
#16 0x00007fffa2732d19 in VstPlugin::tryLoad (this=0x1b6add0, remoteVstPluginExecutable=...) at /home/gnurou/Projects/lmms/lmms/plugins/vst_base/VstPlugin.cpp:183
#17 0x00007fffa27327dc in VstPlugin::VstPlugin (this=0x1b6add0, _plugin=...) at /home/gnurou/Projects/lmms/lmms/plugins/vst_base/VstPlugin.cpp:102
#18 0x00007fffa1bf4f51 in vestigeInstrument::loadFile (this=0x7fffeafb7da0, _file=...) at /home/gnurou/Projects/lmms/lmms/plugins/vestige/vestige.cpp:260
#19 0x00007fffa1bf73f8 in VestigeInstrumentView::openPlugin (this=0x18d8440) at /home/gnurou/Projects/lmms/lmms/plugins/vestige/vestige.cpp:650
#20 0x00007fffa1bfd178 in VestigeInstrumentView::qt_static_metacall (_o=0x18d8440, 
_c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7fffffffd060) at /home/gnurou/Projects/lmms/lmms/build/plugins/vestige/moc_vestige.cxx:217

What is weird is that it seems to happen only on Arch Linux?

Let me know if I can provide more information.

[hydrix9]

confirming from arch x64 with latest versions of wine and lmms

[Narfinger]

I think I tracked down the wait to RemotePlugin.h:293. We are seeming to wait on a semaphore.

Interesting enough, I tried to change to define USE_QT_SEMAPHORES which still crashes lmms in the same way but it gives me the GUI of the VST.

[tresf]

I'd love to reproduce this problem and help troubleshoot, but I simply don't have the patience for a 50 page wiki article to get the OS loaded in a VM and I think this is an unreasonable request for the development team of music software.

Can someone provide a working VM image? By "working", I mean something I can boot and use that is pre-partitioned, has networking installed, a GUI, a boot loader, et. al?

I've skimmed a few quickstart guides, and even the "quick start" guides seem to take hours to complete, which is hours that could be better spent trying to fix this bug.

-Tres

[Wallacoloo]

@tresf you could try one of the Arch-based distros.

And if you're running it in a VM you shouldn't need to do any boot loader stuff.

[tresf]

@tresf you could try one of the Arch-based distros.

Tremedous. I haven't heard of or tried any of those. Any recommendation?

[tresf]

Manjaro Linux seems to be #\8 on distrowatch. I'll check that one out.

Edit: Installed Manjaro, compiling.

sudo pacman -S wine cmake qt4 libsndfile fftw libvorbis libogg alsa-plugins jack\
sdl libsamplerate stk fluidsynth portaudio ftlk libxinerama libxft libgig git gcc-multilib\
lib32-qt4

[Narfinger]

Another thing which I noticed in a debug session is that RemotePluginBase::waitForMessage is busy waiting while zero messages are left. Perhaps isInvalid() is not updated correctly?

[tresf]

Sorry I hadn't yet posted an update on this... My Manjaro install suffers the exact same symptoms of that in the original bug report. shmget: No such file or directory

I think the long term solution is to add better exception handling to our RemotePlugin code. When LMMS talks to an external process (this happens for VST(fx), VST(i) and AFAIK ZynAddSubFX's GUI uses it too).

In the short term, the major troubleshooting issue we have is in these scenarios where our shared memory logic fails with no sign of where or why. Here's an article that explains (perhaps) how we can do better debugging: http://stackoverflow.com/a/7497455/3196753

I believe this is in part due to the choice to use native C++ shared memory for some platforms, but Qt Shared memory for others. I'm making some broad assumptions, but I assume shared memory started as a *nix-Only feature and matured into using Qt's more platform independent implementation for the proprietary platforms, -- such as Windows (and eventually for Mac #698, #703 -- once we get that sorted out)

#1468 (comment)

Although I'm curious if we should just switch our code to use Qt for all platforms, since it comes as a dependency on our codebase anyway. AFAIK, Mac -- for example -- has extremely low SHMEM thresholds when using pure C++. This requires applications to roll their own SHMEM calls. Qt should help circumvent these limitations.

The only person on the project I've ever seen actually understand this remote process complexity is the author, (and the original author of LMMS), @tobydox. Perhaps we'll get lucky and get some insight from him as to how to fix these types of things, or at a minimum, how to debug them.

Another option is to make some more test scenarios and allow Travis-CI to do the RemotePlugin testing for platforms such as Apple, since we have Travis-CI support for that platform.

[kernelcrasher]

Thank you, and thanks a lot for the work.

[tresf]

I see that the split patch in #2390 has passed all checks. Does this mean merge and possibly VSTs loading correctly soon?

The mentioned PR doesn't actually address the VST bug yet per #2390 (comment)

So even when the Ubuntu 12.04 crash is fixed and the code split is merged, the option to use QSharedMemory (as opposed to the native IPC logic which is broken on some platforms, affecting Arch and a few others) won't be directly usable yet per this comment (unless I'm missing something):

I did not yet implement the switching to qt part. In essence this is just using defining the #define USE_QT_SHMEM and #define USE_QT_SEMAPHORES additionally, you need to link and include the correct Qt parts in plugins/vst_base/CMakeList.txt

[kernelcrasher]

From reading the linked issues, WineHQ and the Qt mailing list, it appears that the problem has its roots in the Qt implementation of a function called sendXEmbedMessage(). The arguments are actually passed in the wrong order, which causes everything to break.
See:
https://bugs.winehq.org/show_bug.cgi?id=35347
The issue was reported on the Qt bug tracker in 2014 and has remained unsolved to this day.
(https://bugreports.qt.io/browse/QTBUG-36446)

Seeing as the Linux users are stuck with a bug that makes most virtual instruments unusable with an estimated time to fix of never, is it possible to figure out some workaround?

[Wallacoloo]

Given the name of the function ("X"), perhaps the bug can be avoided by running LMMS under wayland instead of X11?

[tresf]

@Wallacoloo perhaps, but if this is a Qt+Wine bug, I'm not sure how it broke yet again. Perhaps someone reverted the Wine code accidentally in a cleanup effort. I see mentions of QX11EmbedWidget going away with Qt5, so perhaps that's a more viable option?

[YvesPaultre]

So then, installing Qt5 and following the build instructions on the wiki might solve the problem? I'll give that a try and see what works.

EDIT: Apparently I won't. I broke my system trying to get build problems resolved. Gonna have to nuke it and reinstall Ubuntu, thank goodness I keep my home folder in a separate partition...

[amagnolo]

This affects also Lubuntu 15.10 x64 + wine-1.8 + LMMS 1.1.3 from kxstudio repositories.
The tested VSTs (Synth1, Crystal) work all right when loaded in Carla instead of LMMS.

[kamnxt]

Affects LMMS 1.1.90 built from source with wine-1.9.6 on Arch Linux x64.

Tried both 32 and 64 bit VSTs.

[geldedus]

Affects LMMS 1.1.3 (Linux/x86_64, Qt4.8.6, GCC 4.8.2) on Ubuntu 15.10

[kernelcrasher]

It has been over a a year now.
I was wondering if there could be some temporary workaround related to the Qt bug.
Wouldn't it be possible to intentionally pass the arguments in the wrong order so that sendXEmbedMessage actually passes them in the right order?
Also, it seems like someone on WineHQ has produced a temporary workaround:
http://source.winehq.org/patches/data/101921
has this been tested?

[tresf]

has this [workaround] been tested?

Assuming it's the same bug, doesn't that require a patch to X11?

I was wondering if there could be some temporary workaround related to the Qt bug.

There is, @Narfinger wrote one #2304.

Unfortunately, this was closed as the original author of the VST bridge didn't like the idea of pulling IPC support. That spawned a multi-step isolation process...

1. Step 1 - Split the code per Semaphore shm split patch #2390
2. Step 2 - Make Qt method toggle-able

The first step had a bug which is explained the respective PR. No further progress has been made, but please feel free to hack away at it.

[amagnolo]

I'm sorry I don't understand, is there currently any way to use VSTs with LMMS in Linux? Or this feature is broken and was abandoned one year ago?
What's the workaround to this bug, should I change Linux distribution, use an alternative to VeSTige, ...? Please don't tell me to install LMMS in Windows. ;-)

[tresf]

I'm sorry I don't understand, is there currently any way to use VSTs with LMMS in Linux? Or this feature is broken and was abandoned one year ago?

Unless using Carla, not that I'm aware of, at least not on most modern Linux versions (VSTs load fine on Ubuntu 12.04 for me).

What's the workaround to this bug

You could always clone and build the branch in #2304 and try that out, but of course that's not up to date with the stability changes we've had to master.

should I change Linux distribution, use an alternative to VeSTige

Or an alternative to LMMS, if it's a deal breaker for your needs. We need dev help on this.

Please don't tell me to install LMMS in Windows. ;-)

:)

[tresf]

Can someone please test this patch on Arch #2728

I'm testing on ElementaryOS Freya and it seems to be working so as long as I putting the linking back to the old method.

[liushuyu]

I also have the lastest Arch Linux, and I can test this out very soon.

[kernelcrasher]

Anyone tried the patch?

[liushuyu]

Anyone tried the patch?

I have tried this... No it didn't work...

[kernelcrasher]

The Qt bug report has been updated (https://bugreports.qt.io/browse/QTBUG-36446): apparently, they won't patch Qt 4 and Qt 5 doesn't have the functionality that allows for writing host applications.
So, either this is fixed on the LMMS side by adopting some other way of using VSTs, or they will remain permanently unusable.

[jasp00]

According to #2739 (comment), this issue is fixed.

[liushuyu]

According to #2739, this issue is fixed.

[keantoken]

I have this problem on Debian Sid, but only with a 64-bit VST.

RemotePluginClient::shmget: No such file or directory
RemoteVstPlugin.cpp::shmget: No such file or directory
RemoteVstPlugin.cpp: Failed to initialize shared memory for VST synchronization.
(VST-host synchronization will be disabled)

The VST fails to load, and then 'wineserver64 -p0' turns into a zombie and eats my CPU. I am using VSTSynthfont64. The 32-bit version of this synthfont does have this problem.