I will have a look on our side where this re-posting might happen.
On the other hand, if this is a known trick, shouldn't JUCE be prepared for such condition?
I think i understand. I put a dgb() into dispatchMessageFromLParam
void dispatchMessageFromLParam (LPARAM lParam)
{
DBG ("dispatchMessageFromLParam "+String::toHexString((int64)lParam)+"\n");
dispatchMessageFromLParam 285f9618
Post 285f9618
dispatchMessageFromLParam 285f9618
Post 285f9618
dispatchMessageFromLParam 285f9618
dispatchMessageFromLParam 285f9618 (called second time)
Destroy 285f9618
Post 285f9618
dispatchMessageFromLParam 285f9618
Currently I do not see where Cubase would do such a re-post of a message (well, we do, but only at the startup of the app and only for mouse button messages.)
But what I sometimes see is, that 0xc400 messages come in with the same time stamp (MSG.time). Upon suppressing the dispatching of the msg with the same time stamp, the crash goes away...
I wouldn't say it's a "known" trick.. I've don't think I've ever done that myself. It just sounds like the kind of hack that someone may do in this kind of app when trying to deal with plugin windows etc.
I can't think of any sensible way that my code could detect whether a particuloar message has been delivered too many times.. The only way would be to have a complete mirror list of all posted messages and check it each time one arrives, but that'd be a huge burden to add!
Hi Jules,
so you suspect that Cubase is resending the same message again, but actually what I've found is, that your code is doing so.
That means, indeed, the ref counting is working fine, it drops to zero and the CallTimersMessage does get deleted, but in the next round of the timer thread when messageToSend->post() is called, it uses still the same pointer, to the object that just got deleted.
To double check, I've added a simple integer to CallTimersMessage and in the constructor set this to 0x0. Then - and only in the destructor - this integer is set to 0xabcdef. Then, when stopping at messageToSend->post() I can see my abcdef pattern, as well as that the refCount is zero.
If seeing is believing, I can provide you with a download of Cubase 8 and a time limited license.
But that's exactly what I'd expect to see if Cubase was re-posting the win32 message (?)
It sounds like maybe you didn't read or understand my last detailed post explaining exactly what I mean by re-posting?
The only way the ref-count could possibly hit zero and delete the object would be if something other than messageToSend->post() was re-sending the same win32 message somehow, i.e. bypassing the normal juce message posting method. I can't see anything in my code that could possibly do that, which is why I suspect cubase of doing it.
I think jules is right (assumed that MessageManager::postMessageToSystemQueue is the only place where messages are posted).
There are two callbacks, but only one post.
Is there maybe another component/dll (introduced with cubase 7.5) that hacks into the windows messaging chain and doing stupid things?
There must be a reason why it happens now, and not earlier....
Okay, now I understand what Jules is saying. I'll keep looking where that re-post might come from.
And why it's happening now and not earlier? Well, I think it's a timing issue. E.g. opening of Cubase's mixer window became really slow in recent releases (an area where we need to and will improve on). So some long lasting operations must disturb the message dispatching.
Anyway, I'll keep watching...
Thanks Ulf - hope it turns out to be something simple! I'll also keep an eye open in case I have any ideas..
Indeed, it does look like that a message is re-posted. Currently only the lParam is used for the timer message, so I've hacked the wParam to carry a message id and then put out this id to debug output whenever a message is sent or received. Then I'd expect to see always pairs and it does match up, just up until shortly before the crashing, then I see a message id received twice.
I still can't see or find who or where the re-posting happens....
I haven't used Spy++ in years, but it does hook into the messaging system, and if I recall correctly, it displays both when a message is sent, and when it is received. But, I'm also not sure whether there will be any heplful information from this.
Hello guys and especially Jules,
big apologies, because I've now found where and when that reposting is happening. It's actually Cubase's fault and we have to fix it on our side.
Deeply sorry for having created the noise, but it was so difficult to track this all down. And in the end it turns out to be good news for us, because when we can fix it in Cubase, then not JUCE and all of the many plug-ins need to change.
Many thanks to all who followed this thread and tried to help.
Cheers,
Ulf
Just to give a last update, we've found a fix for it and it will appear in the Cubase 8.0.10 maintenance update that is scheduled for end of next month.
Cheers,
Ulf
Hi Ulf, hopefully you read this. There are several threads here in the forum, the problem is always the same. On Macintosh, when closing a project in Cubase , or closing Cubase itself, cubase will crash, when a juce plugin is opened, or a juce plugin has opened an external window. It seems there is some mistake in the order of de-initalisation. Maybe the shared-library (or whatever) is unloaded to fast, before all events are processed, whatever.
If you want to recreate the problem, please send me a p.m.!