Created attachment 144045 [details] Backtrace Hi, here is a backtrace of a crash after a long painting session. Krita crashed while I was running the renderfarm of Pepper&Carrot and was in background. The backtrace contains unusual message, especially ones that appeared on the terminal windows before the crash. I hope it will be useful! If it's not or doesn't contain info, feel free to close it. Krita Plus of 25 November: krita-5.0.0-beta2-8973f9e-20211125-x86_64.appimage Kubuntu 20.04LTS
Git commit 60cbfafef1f2259b22e00201b88562e84a552b50 by Dmitry Kazakov. Committed on 08/12/2021 at 12:27. Pushed by dkazakov into branch 'master'. Make sure that file layers don't ask any questions on every reload M +2 -1 libs/ui/kis_safe_document_loader.cpp https://invent.kde.org/graphics/krita/commit/60cbfafef1f2259b22e00201b88562e84a552b50
Git commit 2e2688b0055afe9806574076889b97b170e59a5d by Dmitry Kazakov. Committed on 08/12/2021 at 12:27. Pushed by dkazakov into branch 'master'. Fix a crash when updating the source of the file layer externally It only happens with the file layers in the clipboard, because they don't have any image attached. Theoretically, it could also happen if the layer was dangling on some widget after the image has been closed. Though the latter case is rather improbable. Steps to reproduce: 1) Create a file later **that scales the source image into the image size**. 2) Copy this layer into the clipboard by "Copy Layer" action 3) Close the image 4) Modify the source of the file layer externally M +26 -16 libs/ui/kis_file_layer.cpp https://invent.kde.org/graphics/krita/commit/2e2688b0055afe9806574076889b97b170e59a5d
Git commit c5725985104a7b961b0a1dbb0543614034691cb5 by Dmitry Kazakov. Committed on 08/12/2021 at 12:28. Pushed by dkazakov into branch 'krita/5.0'. Fix a crash when updating the source of the file layer externally It only happens with the file layers in the clipboard, because they don't have any image attached. Theoretically, it could also happen if the layer was dangling on some widget after the image has been closed. Though the latter case is rather improbable. Steps to reproduce: 1) Create a file later **that scales the source image into the image size**. 2) Copy this layer into the clipboard by "Copy Layer" action 3) Close the image 4) Modify the source of the file layer externally M +26 -16 libs/ui/kis_file_layer.cpp https://invent.kde.org/graphics/krita/commit/c5725985104a7b961b0a1dbb0543614034691cb5
Git commit 2cd152294b24888ab5a34a8de03dd27a3961f3c1 by Dmitry Kazakov. Committed on 08/12/2021 at 12:28. Pushed by dkazakov into branch 'krita/5.0'. Make sure that file layers don't ask any questions on every reload M +2 -1 libs/ui/kis_safe_document_loader.cpp https://invent.kde.org/graphics/krita/commit/2cd152294b24888ab5a34a8de03dd27a3961f3c1
Git commit a06de5df135c14d8335b0589d0099e85d94f316d by Dmitry Kazakov. Committed on 17/12/2021 at 09:50. Pushed by dkazakov into branch 'master'. Fix memory corruptions (and crashes) in File Layers 1) When we copy the image on saving, we will call KisFileLayer::setImage(), which transitively calls to KisFileLayer::slotLoadingFinished(), which could convert the image pointer to the strong one. That could cause a crash, because the image was not constructed yet, therefore its refernce counter was still zero. 2) When we copy the layer into the clipboard and destroy its (temporary) image, we should clear all the references to this layer, such as KisNode::image() and KisNode::graphListener(). Otherwise it could cause a memory corruption, when the layer in the clipboard could call setDirty() on the external image change. Related: bug 441945 M +3 -0 libs/image/kis_image.cc M +3 -1 libs/ui/flake/kis_shape_layer.cc M +27 -2 libs/ui/kis_file_layer.cpp https://invent.kde.org/graphics/krita/commit/a06de5df135c14d8335b0589d0099e85d94f316d
Git commit 763bd11a7eb85953afc101a00882d27b2d69a07a by Dmitry Kazakov. Committed on 17/12/2021 at 09:51. Pushed by dkazakov into branch 'krita/5.0'. Fix memory corruptions (and crashes) in File Layers 1) When we copy the image on saving, we will call KisFileLayer::setImage(), which transitively calls to KisFileLayer::slotLoadingFinished(), which could convert the image pointer to the strong one. That could cause a crash, because the image was not constructed yet, therefore its refernce counter was still zero. 2) When we copy the layer into the clipboard and destroy its (temporary) image, we should clear all the references to this layer, such as KisNode::image() and KisNode::graphListener(). Otherwise it could cause a memory corruption, when the layer in the clipboard could call setDirty() on the external image change. Related: bug 441945 M +3 -0 libs/image/kis_image.cc M +3 -1 libs/ui/flake/kis_shape_layer.cc M +27 -2 libs/ui/kis_file_layer.cpp https://invent.kde.org/graphics/krita/commit/763bd11a7eb85953afc101a00882d27b2d69a07a