Windows Bluetooth: gracefully handle device disconnect during detailed service discovery

Discovering service details in an asynchronous process, which means
that the user may actually disconnect from the device while the
discovery is still in progress.

This means that we could end up in a situation when the
discoverServiceDetailsHelper() is called with an empty serviceList.
In this case, requesting for a specific service from the serviceList
returns a nullptr, which may later lead to a crash. Add a nullptr
check to gracefully handle such situations.

Fixes: QTBUG-119060
Pick-to: 6.6 6.5
Change-Id: Iebdff67a12e6550979535ae5bac659ddae57b010
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
(cherry picked from commit 35f853837793b6d526815140021013cf03cc80b5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

1 files changed, 4 insertions, 0 deletions

diff --git a/src/bluetooth/qlowenergycontroller_winrt.cpp b/src/bluetooth/qlowenergycontroller_winrt.cpp
index 99f33dad..6914ed42 100644
--- a/src/bluetooth/qlowenergycontroller_winrt.cpp
+++ b/src/bluetooth/qlowenergycontroller_winrt.cpp
@@ -1231,6 +1231,10 @@ void QLowEnergyControllerPrivateWinRT::discoverServiceDetailsHelper(
     };
     //update service data
     QSharedPointer<QLowEnergyServicePrivate> pointer = serviceList.value(service);
+    if (!pointer) {
+        qCDebug(QT_BT_WINDOWS) << "Device was disconnected while doing service discovery";
+        return;
+    }
     qCDebug(QT_BT_WINDOWS_SERVICE_THREAD) << __FUNCTION__ << "Changing service pointer from thread"
                                           << QThread::currentThread();
     pointer->setState(QLowEnergyService::RemoteServiceDiscovering);