https://bugs.kde.org/show_bug.cgi?id=505583
rubin110 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from rubin110 <[email protected]> --- Additional data point: same root cause (Windows Bluetooth backend), different crash signature, on a much newer Qt. Environment: - KDE Connect 26.04.2 (Microsoft Store package 26.402.6289.0) - Qt 6.11.1.0 (this build bundles Qt6Bluetooth.dll 6.11.1.0) - Windows 11 Pro, OS build 26200 (ntdll.dll 10.0.26100.8521), x86_64 Symptom: kdeconnectd.exe crashes repeatedly. Exception code 0xC00000FD (STATUS_STACK_OVERFLOW), faulting module ntdll.dll, i.e. unbounded recursion, not the 0xc0000005 access violation in the original report. Roughly 460 crashes over 4 days, in bursts at a near-constant ~66s cadence (crash, indicator relaunches the daemon, ~60s, crash). User-visible effect is that KDE Connect features (clipboard, etc.) intermittently stop until the daemon is restarted. Minidump analysis: the crashing thread's stack is a re-entrant Qt event-loop recursion ~1322 frames deep, identical across multiple dumps. Per-iteration cycle, symbolized by nearest export (the release build ships no PDBs, so the kdeconnectcore/Qt6Bluetooth frames are private functions past the export table): kdeconnectcore.dll +0x6cfac, +0x6f8e4 (nearest export: BluetoothLinkProvider::onNetworkChange()) Qt6Core.dll QMetaObject::activate (+0x84), qt_static_metacall (signal emit / slot dispatch) Qt6Core.dll QIODevice::write(QByteArray) / write(char*,qint64) / bytesWritten Qt6Bluetooth.dll +0x5e24c, +0x5e50a (nearest export: QBluetoothServer::setMaxPendingConnections) twinapi.appcore.dll +0x224d60 + Windows.Networking.dll (WinRT app/networking backend) It recurses through QMetaObject::activate until the 1 MB thread stack overflows. Two findings worth flagging. 1. disabled_providers=BluetoothLinkProvider does NOT prevent this. core/daemon.cpp constructs and calls onStart() on every link provider unconditionally, the "disabled" flag is only a constructor argument applied after construction, so the Qt6Bluetooth code path runs regardless of config. 2. Controlled reproduction and mitigation: turning the Windows Bluetooth radio OFF stops the crash loop immediately and completely (the daemon went from never surviving >66s to stable indefinitely, zero further crashes or dumps); turning it back ON resumes the loop. That pins the trigger to the Qt/WinRT Bluetooth backend. Likely Qt-layer cause: QTBUG-109510 (Qt6 WinRT Bluetooth re-entrant event-loop and infinite recursion on Windows 11), still present in Qt 6.11.1. https://qt-project.atlassian.net/browse/QTBUG-109510 This looks like the stack-overflow variant of the Qt6Bluetooth Windows crash in this report (the underlying instability persists from Qt 6.8.1 through 6.11.1), and it reinforces the request to not enable the Bluetooth backend by default on Windows, and/or to honor disabled_providers before the provider is constructed and started. -- You are receiving this mail because: You are watching all bug changes.
