Jasserts in CMake AudioPlugin example on Unbuntu with JRiver

Linux
1

Juce 7.0.2, Ubuntu 20.04.5 LTS, Visual Studio Code 1.73.1 with C++ and CMake extensions. Using the Juce CMake example project AudioPlugin.

I can build and run in the debugger launching AudioPluginHost and Repear with no issues.

But launching and running in JRiver Media Center, I run into these jasserts:

In juce_VST3_Wrapper.cpp line 272

 static Steinberg::Linux::IRunLoop* getRunLoopFromFrame (IPlugFrame* plugFrame)
    {
        Steinberg::Linux::IRunLoop* runLoop = nullptr;

        if (plugFrame != nullptr)
            plugFrame->queryInterface (Steinberg::Linux::IRunLoop::iid, (void**) &runLoop);

        jassert (runLoop != nullptr);
        return runLoop;
    }

F5 to juce_Component.cpp line 662

void Component::addToDesktop (int styleWanted, void* nativeWindowToAttachTo)
{
    // if component methods are being called from threads other than the message
    // thread, you'll need to use a MessageManagerLock object to make sure it's thread-safe.
    JUCE_ASSERT_MESSAGE_MANAGER_IS_LOCKED

    if (isOpaque())
        styleWanted &= ~ComponentPeer::windowIsSemiTransparent;
    else
        styleWanted |= ComponentPeer::windowIsSemiTransparent;

F5 to juce_linux_Windowing.cpp line 43

class LinuxComponentPeer  : public ComponentPeer,
                            private XWindowSystemUtilities::XSettings::Listener
{
public:
    LinuxComponentPeer (Component& comp, int windowStyleFlags, ::Window parentToAddTo)
        : ComponentPeer (comp, windowStyleFlags),
          isAlwaysOnTop (comp.isAlwaysOnTop())
    {
        // it's dangerous to create a window on a thread other than the message thread.
        JUCE_ASSERT_MESSAGE_MANAGER_IS_LOCKED

        const auto* instance = XWindowSystem::getInstance();

F5 to juce_Component.cpp line 1950

void Component::internalRepaintUnchecked (Rectangle<int> area, bool isEntireComponent)
{
    // if component methods are being called from threads other than the message
    // thread, you'll need to use a MessageManagerLock object to make sure it's thread-safe.
    JUCE_ASSERT_MESSAGE_MANAGER_IS_LOCKED

    if (flags.visibleFlag)

F5 juce_Component.cpp line 958

void Component::toFront (bool shouldGrabKeyboardFocus)
{
    // if component methods are being called from threads other than the message
    // thread, you'll need to use a MessageManagerLock object to make sure it's thread-safe.
    JUCE_ASSERT_MESSAGE_MANAGER_IS_LOCKED_OR_OFFSCREEN

    if (flags.hasHeavyweightPeerFlag)

And a few more F5’s and the window displays, no issues. Closing the window (i.e. editor) produces the final jassert which is back to the getRunLoopFromFrame.

Any ideas to the cause of these jasserts?

2

On Linux, JUCE’s VST3 editor expects to attach to an IRunLoop provided by the host. According to the documentation for IRunLoop in the VST3 header file, “On Linux the host has to provide this interface to the plug-in as there’s no global event run loop defined as on other platforms.”

The assertions you’re seeing would be hit if the host fails to provide this interface. There’s no workaround for this on the plug-in side. The host needs to be updated so that it provides this interface on Linux.

1 Like