tiled
tiled copied to clipboard
Possible crash in `AbstractWorldTool::undoStack` when switching maps
The following crash was reported through Sentry:
Thread 28281 Crashed:
0 libtilededitor.so 0x7f1b4e333c47 Tiled::AbstractWorldTool::undoStack (abstractworldtool.cpp:397)
1 libtilededitor.so 0x7f1b4e4a5691 Tiled::MapEditor::updateActiveUndoStack (mapeditor.cpp:684)
2 libtilededitor.so 0x7f1b4e4acc34 Tiled::MapEditor::setCurrentDocument (mapeditor.cpp:379)
3 libtilededitor.so 0x7f1b4e3ed36c Tiled::DocumentManager::currentIndexChanged (documentmanager.cpp:982)
4 libQt6Core.so.6 0x7f1b4c797771 [inlined] QtPrivate::QSlotObjectBase::call (qobjectdefs_impl.h:363)
5 libQt6Core.so.6 0x7f1b4c797771 doActivate<T> (qobject.cpp:3979)
6 libQt6Widgets.so.6 0x7f1b4dd6c5cd QTabBar::currentChanged (moc_qtabbar.cpp:425)
7 libQt6Widgets.so.6 0x7f1b4dd73ad3 QTabBar::removeTab (qtabbar.cpp:1063)
8 libtilededitor.so 0x7f1b4e3f4228 Tiled::DocumentManager::closeDocumentAt (documentmanager.cpp:865)
9 libQt6Core.so.6 0x7f1b4c797771 [inlined] QtPrivate::QSlotObjectBase::call (qobjectdefs_impl.h:363)
10 libQt6Core.so.6 0x7f1b4c797771 doActivate<T> (qobject.cpp:3979)
11 libtilededitor.so 0x7f1b4e3ecaa4 Tiled::DocumentManager::documentCloseRequested (moc_documentmanager.cpp:635)
12 libQt6Core.so.6 0x7f1b4c797771 [inlined] QtPrivate::QSlotObjectBase::call (qobjectdefs_impl.h:363)
13 libQt6Core.so.6 0x7f1b4c797771 doActivate<T> (qobject.cpp:3979)
14 libQt6Widgets.so.6 0x7f1b4dd6c610 QTabBar::tabCloseRequested (moc_qtabbar.cpp:432)
The crash occurs on the last line of this function:
https://github.com/mapeditor/tiled/blob/cb4c33c599c811e0379cc4669e1bea77f258de3a/src/tiled/abstractworldtool.cpp#L392-L398
It is clear that even though WorldManager::worldForMap returned a World*, the DocumentManager::ensureWorldDocument did not have a matching WorldDocument instance. Matching instances are supposed to always be available based on these connections:
https://github.com/mapeditor/tiled/blob/cb4c33c599c811e0379cc4669e1bea77f258de3a/src/tiled/documentmanager.cpp#L278-L282
I'm not sure yet what could cause this issue, but I think this approach is a little too fragile in any case.