i ran some tests on wavelab 4 Demo , but th gui of my plugin got frozen.
One Thread is hanging here, tries to get the MM lock:
juce::CriticalSection::enter() Line 81 + 0xc bytes C++
juce::MessageManagerLock::MessageManagerLock() Line 340 C++
JuceVSTWrapper::doIdleCallback() Line 851 + 0x8 bytes C++
JuceVSTWrapper::dispatcher(int opCode=19, int index=0, int value=0, void * ptr=0x00000000, float opt=0.00000000) Line 946 C++
AudioEffect::dispatchEffectClass(AEffect * e=0x0399c588, int opCode=19, int index=0, int value=0, void * ptr=0x00000000, float opt=0.00000000) Line 32 + 0x26 bytes C++
The other is hanging in a Windows Messaging Routine “DefWindowProc”
juce::Win32ComponentPeer::peerWindowProc(HWND__ * h=0x001506d6, unsigned int message=32, unsigned int wParam=1378006, long lParam=33554433) Line 2044 + 0x18 bytes C++
Well it’s a deadlock - juce is dispatching a message, which is getting passed onto wavelab, but for some reason it’s making an idle callback at the same time on a different thread (most hosts do it on the same thread).
Looking at the windowing code again, I’ve changed it now to release the message lock before that last defwindowproc call. Get the tip from sourceforge and see if it helps…
the problem still occurs when opening a popup, or file-selector.
I seems that maybe a other thread, with no debugging information locks the MM?
by the way, i uncommented checkMessageManagerIsLocked in juce_component.cpp , to see why the gui freezes in release mode.
So i can see whats happening in debug mode.
The main problem is that wavelab use more then one thread for messaging , but i have to find a solution for this, wavelab is very important.
When opening a popup menu in the gui, the MM is locked in “deliverMessage”. This results in “GetMessage” (user32.dll) which results in
windowProc.
Together with the doIdleCallback() from the other thread, we have the same deadlock situation.
The whole call stack:
ntdll.dll!7c91eb94()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
user32.dll!7e3694be()
user32.dll!7e36b42d()
user32.dll!7e36b3f9()
user32.dll!7e36b393()
plugin_debug.dll!juce::Win32ComponentPeer::peerWindowProc(HWND__ * h=0x0002097a, unsigned int message=32, unsigned int wParam=133498, long lParam=33554433) Line 2104 + 0x18 bytes C++
plugin_debug.dll!juce::Win32ComponentPeer::windowProc(HWND__ * h=0x0002097a, unsigned int message=32, unsigned int wParam=133498, long lParam=33554433) Line 1744 + 0x18 bytes C++
user32.dll!7e368734()
user32.dll!7e368816()
user32.dll!7e3818e3()
user32.dll!7e36b4c0()
user32.dll!7e36b50c()
ntdll.dll!7c91eae3()
user32.dll!7e3691be()
user32.dll!7e37e042()
plugin_debug.dll!juce::juce_dispatchNextMessageOnSystemQueue(bool returnIfNoPendingMessages=false) Line 111 + 0x12 bytes C++
plugin_debug.dll!juce::MessageManager::dispatchNextMessage(const bool returnImmediatelyIfNoMessages=false, bool * const wasAMessageDispatched=0x00000000) Line 150 + 0x9 bytes C++
plugin_debug.dll!juce::Component::runModalLoop() Line 1448 + 0x10 bytes C++
plugin_debug.dll!juce::PopupMenu::showMenu(const int x=630, const int y=465, const int w=1, const int h=1, const int itemIdThatMustBeVisible=0, const int minimumWidth=0, const int maximumNumColumns=0, const int standardItemHeight=0, const bool alignToRectangle=false, juce::Component * const componentAttachedTo=0x00000000) Line 1618 + 0x8 bytes C++
plugin_debug.dll!juce::PopupMenu::showAt(const int screenX=630, const int screenY=465, const int itemIdThatMustBeVisible=0, const int minimumWidth=0, const int maximumNumColumns=0, const int standardItemHeight=0) Line 1672 C++
plugin_debug.dll!juce::PopupMenu::show(const int itemIdThatMustBeVisible=0, const int minimumWidth=0, const int maximumNumColumns=0, const int standardItemHeight=0) Line 1658 C++
plugin_debug.dll!test_plugin_editor_window::chkn_PictureContainerChanged(chkn_PictureContainer * sp=0x040107c8) Line 2072 + 0x13 bytes C++
plugin_debug.dll!chkn_PictureContainer::handleAsyncUpdate() Line 117 + 0x31 bytes C++
plugin_debug.dll!juce::AsyncUpdater::handleUpdateNowIfNeeded() Line 69 + 0xf bytes C++
plugin_debug.dll!juce::AsyncUpdater::AsyncUpdaterInternal::handleMessage(const juce::Message & __formal={...}) Line 76 C++
> plugin_debug.dll!juce::MessageManager::deliverMessage(void * message=0x04009630) Line 111 + 0x13 bytes C++
plugin_debug.dll!juce::juce_MessageWndProc(HWND__ * h=0x00040a74, unsigned int message=50176, unsigned int wParam=0, long lParam=67147312) Line 78 C++
Ok, well we’ve got to stop that idle call doing anything bad. How about this hack:
[code] void doIdleCallback()
{
if (MessageManager::getInstance()->isThisTheMessageThread())
{
if (! recursionCheck)
{
const MessageManagerLock mml;
recursionCheck = true;
juce_callAnyTimersSynchronously();
for (int i = ComponentPeer::getNumPeers(); --i >= 0;)
ComponentPeer::getPeer (i)->performAnyPendingRepaintsNow();
recursionCheck = false;
}
}
}
[/code]
It should sort out the deadlock, though might have other effects on the reapinting, etc, so I’d be interested to hear how it goes (I don’t have wavelab to try it myself).
