https://bugs.kde.org/show_bug.cgi?id=519587
Thomas Whitecotton <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Thomas Whitecotton <[email protected]> --- I am hitting the same crash repeatedly on kdeconnect 26.04.1 (Arch / CachyOS) against my Galaxy Z Fold7. Identical backtrace, identical file:line. In my case 20 SIGSEGVs in ~3 minutes from a single conversationID before the phone-side state cleared on its own. One piece of evidence that was missing from the original report: there's exactly one warning in the journal right before each crash: kdeconnectd[NNN]: Got a conversationID for a conversation with no messages! <ID> That comes from `RequestConversationWorker::handleRequestConversation()` (`plugins/sms/requestconversationworker.cpp` around line 35), which logs the warning and then continues into `replyForConversation()` with the empty list. The existing comment next to the warning is... honest(?) about the choice: // Since there are no messages in the conversation, it's likely that it is a junk ID, but go ahead anyway `replyForConversation()` does `conversation.crbegin() + start` on the empty `QList`, which for any non-zero `start` is past-the-end (UB), the loop body runs, and `*it` is dereferenced inside `QVariant::fromValue` - matching the `QMetaTypeForType<ConversationMessage>::getCopyCtr` frame in the backtrace. The 10-second crash loop is because kdeconnectd is D-Bus auto-activated: it crashes, gets restarted, re-fetches the same offending conversation, re-crashes. Loop continues until the phone stops advertising the bad conversation - in your case after a phone reboot creates a stale entry in the SMS sync index, in mine after a thread is deleted on the phone while the desktop holds a reference. Patch is up as MR !962: https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/962 -- You are receiving this mail because: You are watching all bug changes.
