Tooltip crash

[RiphRaph]

Hi,
There's a bug with the tooltips on the VST PC audio plugins. RTAS PC plugins and Mac plugins don't crash.
Printing tooltips on screen makes my VST plugin crash at the DAW closing (Reaper, Cubase, Live).
I've done a quick test by simply adding a tooltip to a slider of the demo plugin and the crash also happens.

PluginEditor.h:

Code: Select all

   ScopedPointer<TooltipWindow> tooltipWindow;


PluginEditor.cpp: in the constructor

Code: Select all

   tooltipWindow = new TooltipWindow(this, 0);
...
   gainSlider.setTooltip("Hello");


Other info:
- DirectWrite is not activated.
- The bug occurs since I've been using the new "modules" library. Plugins built with juce version prior to 1.54.27 work fine.
- Juce version: 2.0.21
- same problem on 32 and 64-bit plugins

Any ideas how to fix it?
Thanks

[jules]

You'll be deleting a dangling pointer. I bet you're calling deleteAllChildren() in your editor, and so deleting the tooltip window twice.

[chkn]

Debug it - would like to see the callstack.

Jules: there are sometimes issues with open windows after the plugin gets destroyed by the host (but my problem is on mac side http://rawmaterialsoftware.com/viewtopic.php?f=8&t=8671 )
Do you see any way to dispatch the message-thread after all windows are closed, before the plugin instance gets destroyed ?

[jules]

In this case he's adding the tooltip to the editor, not putting it on the desktop.

Clearing out the message queue is an old problem, and AFAIK no perfect solution is possible from the plugin's side.

[chkn]

ooops

[RiphRaph]

No I haven't got any deleteAllChildren() in my destructor. And as I said, the demo plugin, which has a empty destructor, crashes too.
It might come from juce_VST_wrapper.cpp that doen't properly close down the editor.

The DAW callstack doesn't help, as you can see:

Code: Select all

   
ntdll.dll!76f99b01()    
   [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]   
   ntdll.dll!76fb7d8a()    
   ntdll.dll!76fb801e()    
   ntdll.dll!76fb8256()    
   kernel32.dll!755a3677()    
   ntdll.dll!76f99f42()    
   ntdll.dll!76f99f15()


[chkn]

-edit deleted

[jules]

Ah, I see.. well that doesn't even look like there's any of the plugin's code on the callstack. This sounds like it might be what chkn suggested, i.e. the host doesn't provide enough time for the window to get deleted before unloading the dll. Tricky to work around that one, but you could try deleting the window and briefly running he message loop to let it clear up.

[RiphRaph]

What do you mean by running the message loop?

[jules]

I mean using MessageManager::runDispatchLoopUntil. It's very dangerous to do this, but if the host doesn't give the plugin chance to clear up, it can sometimes be the only option.

[RiphRaph]

I finally sorted out!
I thought JUCE_USE_DIRECTWRITE was undefined as it is uncommented in AppConfig.h but in fact it is defined in juce_graphics.h.
I followed the tooltip drawing trace up to TextLayout::createNativeLayout() in juce_win32_DirectWriteTypeLayout.cpp to figure it out.
So I commented JUCE_USE_DIRECTWRITE out and now it works fine.

[gbevin]

In this case he's adding the tooltip to the editor, not putting it on the desktop.

Clearing out the message queue is an old problem, and AFAIK no perfect solution is possible from the plugin's side.

Jules, any recommendations on what's the best thing to do here on the host's side? How to make sure that there are no more messages that are going to be processed for a plugin after the editor is closed and before destroying it?

Thanks,

Geert

[jules]

How to make sure that there are no more messages that are going to be processed for a plugin after the editor is closed and before destroying it?

Unfortunately it's impossible to make sure the host doesn't unload your DLL while messages are pending. Like I already said, the only thing we can do from the plugin's side is to spin the message loop briefly (which can be dangerous).

[gbevin]

How to make sure that there are no more messages that are going to be processed for a plugin after the editor is closed and before destroying it?

Unfortunately it's impossible to make sure the host doesn't unload your DLL while messages are pending. Like I already said, the only thing we can do from the plugin's side is to spin the message loop briefly (which can be dangerous).

Yes, I understand that, I was asking about the host side. Any recommendations for what a host should do after the plugin editor is closed. Just wait for a while? Run the dispatch thread for a while? Anything else?

Thanks

[jules]

Oh, I see. Well, for the host it's easy: just don't unload DLLs immediately when the plugin is closed. When you'd normally unload a DLL, just kick off a timer instead that'll do it after a couple of seconds.