Created attachment 117992 [details] Backtrace generated by the KCrash handler after the segfault SUMMARY Trojitá crashes when several network actions are enqueued and NetworkManager reconnects to the network after Wi-Fi failure. STEPS TO REPRODUCE The problem is not easily reproducible, so I guess that it depends on some context which I didn't take into account. But it happpened twice in a single month, so I think it is not just a fluke. 1. Have a stuck / unresponsive network, i.e. have NetworkManager announce connectivity without it actually working. 2. Open another mailbox and try to read an uncached message. 3. Reconnect to a working network. OBSERVED RESULT Trojitá crashes with the attached backtrace. EXPECTED RESULT Trojitá preferrably cleanly reconnects and performs all the enqueued actions, or alternatively cleans the queue and does nothing. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION A backtrace is in the attachment.
Thanks for reporting this and thanks for providing a usable backtrace, Jonáš. Here's a brief analysis of what might be happening, but I do not currently have time to dig into this deeper. Rapid network reconnects result in invalidating subtrees of our QAbstractItemModel subclass. This is not a problem, the code "should be designed" with this in mind. There are plenty of Q_ASSERT macros which enforce this assumption, guaranteeing that the app crashes reasonably cleanly whenever there's a code bug (i.e., when the code assumes that, say, a given message is still available in the model tree, while it got "invalidated" by a rescan upon a network reconnect). The problem is that these assertions are removed in release builds. Unless you've built with USE=debug, you do not have these assertions, and the code no longer dies "soon enough". It might keep working over invalidated QModelIndex instances for a short while, hitting a segfault when the memory has been finally repurposed and/or corrupted. If this is all correct, then this sounds like a duplicate of https://bugs.kde.org/show_bug.cgi?id=392800 . Looking at the date of filing and its history, it's indeed rather hard to reproduce that one :(. *** This bug has been marked as a duplicate of bug 392800 ***
Thank you for the analysis. Indeed, I built the package without assertions. I'll rebuild it with USE="debug" and try to reproduce the bug.