UI Freezes when switching networks


#1

Hello,
i’m on Win 10 x64 latest update (Fall Creators)

I’ve been having an issue since a long time with apps made with JUCE freezing / hanging in a weird way when the wifi is disconnected and i’m connecting to a network while the app is running.
I’m usually using OSC in my apps, i suspect there might be a problem with that i don’t really know.
When debugging with VS, having this problems results to a completely frozen app but the debugger is not detecing any problem and keeps running.
When the problem occurs without active VS debugging (Release AND Debug apps launched from the explorer), the app freezes then Windows takes on it and offers to kill the app (white alpha-50% overlay)

I’ve been building around 10 apps since 2 years now and they all have the same problem.
I’ve also noticed that Resolume, which if i’m not mistaken is also JUCE based actually has a similar problem !

Does anybody can relate to this problem ? Some of my apps are starting to spread out quickly and the problem becomes quite annoying as i get more and more feedback for that kind of crash, and since my apps are made for live shows essentially, it’s really not convenient.

Thanks !


#2

So if you hit pause in the debugger when your app is frozen, are any threads waiting anywhere interesting?

Can you provide a minimal working example? Just going through the process of doing this is likely to narrow down the problem a little further.


#3

I can’t reproduce it systematically, it happens often but i don’t really know when…

From what i remember, when i hit pause, it seems to loop on drawing functions, didn’t seemed much relevant.

I’ll be sure to post the stack trace when it appears again !


#4

Ok, i think i’ve caught the problem !
I have 3 osc receivers and 3 senders running, some sending on localhost and some sending on the local network.

At some point, the UI freezes and when i hit pause, i get this stack trace :

 |>|OSCMorph.exe!juce::SocketHelpers::waitForReadiness(const volatile int & handle, juce::CriticalSection & readLock, const bool forReading, const int timeoutMsecs) Line 280|C++|Symbols loaded.|
|---|---|---|---|
| |OSCMorph.exe!juce::DatagramSocket::waitUntilReady(bool readyForReading, int timeoutMsecs) Line 674|C++|Symbols loaded.|
| |OSCMorph.exe!juce::OSCReceiver::Pimpl::run() Line 459|C++|Symbols loaded.|
| |OSCMorph.exe!juce::Thread::threadEntryPoint() Line 96|C++|Symbols loaded.|
| |OSCMorph.exe!juce::juce_threadEntryPoint(void * userData) Line 115|C++|Symbols loaded.|
| |OSCMorph.exe!juce::threadEntryProc(void * userData) Line 76|C++|Symbols loaded.|
| |OSCMorph.exe!invoke_thread_procedure(unsigned int(*)(void *) procedure, void * const context) Line 92|C++|Symbols loaded.|
| |OSCMorph.exe!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void * const parameter) Line 115|C++|Symbols loaded.|

The waitForReadiness function seems to have a good name for a thread-blocking issue like this one :slight_smile: