Apologies if this is problem is covered elsewhere but I can’t seem to find a reference to it. I wrote a utility program to test some wrapper classes I put round JUCE for transferring compressed audio and video over a network or the internet. The user interface is effectively a web control showing an html page with buttons and fields on a form for configuring the audio visual call. The app works fine but there is a curious problem if I leave it dormant. After a delay of a few minutes when running on 64-bit Windows 7 the Visual Studio debugger stops at this line in the JUCE library in juce_Timer.cpp: // If you’re calling this before (or after) the MessageManager is // running, then you’re not going to get any timer callbacks!
jassert (MessageManager::getInstanceWithoutCreating() != nullptr);
Any suggestions? Is this due to something I should have done, or possibly a JUCE bug?
I suspect it must be specific to your app, otherwise I’m sure we’d have seen it before… It sounds like something has caused a shutdown somehow - you might want to check what all the threads are doing at the point where this happens. Or try to create some test code that reproduces it if you want us to take a look.
Thanks. It helps to know it’s not a known problem. If this jassert was occurring when my app was processing audio and video I would have certainly suspected my own code, but the jassert is occurring when it is just sitting there waiting for preliminary user input. Next time it occurs I will make a more thorough investigation and get back to you.
Thanks - I don’t think there’s much we could do without more info. Certainly there are lots of JUCE apps constantly just sitting around without this happening so there must be something fishy going on!
What happens if you add a breakpoint to the MessageMananager destructor? I’d suspect that you somehow deinitialise the GUI when going to sleep.
Thank you. I will look into that. This problem has occurred often enough
that I should be able to find the conditions to reproduce it reliably
and it does always happen when the application is inactive, not
processing any audio or video, merely displaying a screen awaiting
input. Also, I suspect, when I am engaged with another computer so that
I haven’t touched keyboard or mouse for some minutes. My PC settings are
that screen saver comes on after 11 minutes inactivity, display turned
off after 15 minutes inactivity, computer put to sleep never.
I am now able to predictably recreate the problem. I thought it might be
when my screen saver or power saver display shutdown kicked in, but
tests showed that it wasn’t. The initiator of the problem is this: My
main Windows 7 development machine is connected to a second monitor via
an HDMI switch which allows me to use the monitor as a second monitor
for my main PC or as a monitor for my Linux box or my Mac mini. I can
also turn off the HDMI switch, which has the effect of moving all the
Windows 7 windows I had displayed on my second monitor back to the main
monitor. It is this action of turning the hdmi switch off that triggers
the problem. Here is the stack trace at that point:
I slightly changed the JUCE code so I could set a breakpoint:
void Timer::startTimer (const int interval) noexcept
{
// If you’re calling this before (or after) the MessageManager is
// running, then you’re not going to get any timer callbacks!
MessageManager * instance =
MessageManager::getInstanceWithoutCreating() ;
// ADDED CODE
if ( instance == NULL )
{
int x = 0 ;
x++ ; // set breakpoint here
}
else
// END OF ADDED CODE
{
jassert (MessageManager::getInstanceWithoutCreating() != nullptr);
}
Curiously I also have a breakpoint set here
void
MessageManager::deleteInstance()
{
deleteAndZero (instance); // b.p. set
}
thinking that I could trap the zeroing of the static pointer before the
call to startTimer, but this breakpoint is not hit. Any suggestions?
Regards
Sahlan Diver
Sorry, I tried to paste the call stack trace as an image. Here it is as text instead:
alvmediaud.dll!juce:
:startTimer(int interval) Line 316 C++
alvmediaud.dll!juce::DeviceChangeDetector::triggerAsyncDeviceChangeCallback() Line 116 C++
alvmediaud.dll!juce::WasapiClasses::WASAPIAudioIODeviceType::ChangeNotificationClient::notify() Line 1513 C++
alvmediaud.dll!juce::WasapiClasses::WASAPIAudioIODeviceType::ChangeNotificationClient::OnDeviceStateChanged(const wchar_t * __formal, unsigned long __formal) Line 1506 C++
MMDevAPI.dll!658d3b12() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for MMDevAPI.dll]
MMDevAPI.dll!658c96d5() Unknown
MMDevAPI.dll!658c1674() Unknown
ntdll.dll!7705747e() Unknown
ntdll.dll!77040951() Unknown
kernel32.dll!74ac336a() Unknown
ntdll.dll!77029902() Unknown
ntdll.dll!770298d5() Unknown
That’s very odd, I can’t see how the MessageManager could possibly be a nullptr until the app is being shut down and that breakpoint would be hit… Maybe there’s something dodgy happening on a different thread when this happens?