Possible crash in BLEDeviceWatcher at shutdown

The following stacktrace show that ~MidiService clears WinRTWrapper singleton instance in the desctructor. The stacktrace also shows that DeviceCallbacksHandler::detach is called later on in the same thread. DeviceCallbacksHandler::detach “deregisters” the callsbacks that are registered in DeviceEnumerationThread::run. Inside the callsbacks there is for example a call to handlerPtr->addDevice (info). handlePtr could be pointing to a BLEDeviceWatcher instance, and in BLEDeviceWatcher::addDevice there is this call

auto deviceID = WinRTWrapper::getInstance()->hStringToString (deviceIDHst);

… and since the singleton is cleared in the dtor of MidiService, the above call could be a nullptr being dereferenced, since the callbacks are deregistered after the WinRTWrapper singleton is cleared.

I’m not sure I follow. The call to clearSingletonInstance() in the MidiService destructor will clear the MidiService singleton, not the WinRTWrapper singleton. Also, calling getInstance() on a JUCE singleton will create the singleton if it doesn’t exist, unlike getInstanceWithoutCreating(), so there’s no likelihood of dereferencing a deleted object.

yes you are correct.

but there seems to be a problem with the order of destruction. It seems that WinRtWrapper singleton can be destroyed before the call DeviceCallbacksHandler::detach.

If I put a breakpoint where the WindRTWrapper singleton is cleared:

…then that always happen before the call to DeviceCallbacksHandler::detach (see previous stacktrace in the first post. They both come from DeletedAtShutdown::deleteAll()

I see now, thanks. I’ve pushed a fix to the develop branch here which should cope better in the rare situations where the WinRTWrapper gets deleted whilst the MIDI service is cleaning up.

Great! The crash I got before is not happening any longer.