The same ASSERT is done in removeTab(..) but at this point here was observed that it could happens, e.g. while session restore
Details
- Reviewers
dhaumann cullmann - Group Reviewers
Kate - Commits
- R40:64e1cc6bdd17: try to avoid crash during tab adding/removal
Diff Detail
- Repository
- R40 Kate
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Out of the blue run I into this issue.
The only slightly unusual before was, that I had a confirmation box regarding an unsaved file while quit the session. Then, when I want to restart the same session, it crached always.
If you like I can submit the BT, but think it's not needed to approve this patch.
Hmm, the internal state is really broken if that doesn't work.
I don't think this check will really solve the issue.
Had you any chance to see a backtrace with e.g. the index?
Hmm, perhaps the restore view stuff does create the issues:
// restore Document lru list so that all tabs from the last session reappear const QStringList lruList = group.readEntry("Documents", QStringList()); for (int i = 0; i < lruList.size(); ++i) { auto doc = KateApp::self()->documentManager()->findDocument(QUrl(lruList[i])); if (doc) { const int index = m_lruDocList.indexOf(doc); if (index < 0) { registerDocument(doc); Q_ASSERT(m_lruDocList.contains(doc)); } else { m_lruDocList.removeAt(index); m_lruDocList.append(doc); } } }
the else case with the lruDocList changes might mess up some lru => tab order, or?
hm, can't say much helpful to your patch. Send you my BT.
But from my point of view is this assert here redundant. When you dislike my check, you can drop the assert anyway.
I'm sorry, I couldn't reproduce the crash to verify your patch. But at least cause it on the first sight no new crash here :-)
Then we try that patch in master.
I think re-shuffling the indices there is no good idea.