| Summary: | Unable to save Artwork in any format(kra,jpeg) | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | chrispeterf |
| Component: | File formats | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | dimula73, halla |
| Priority: | NOR | ||
| Version: | 5.2.3 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/-/commit/706b558625d79f27cb8f774ea408b1540d08a719 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
screenshot of the issue facing
attachment-3247666-0.html |
||
|
Description
chrispeterf
2024-11-09 17:13:17 UTC
Hi, Chris! Please try to stop the recorder plugin. Might make the image busy Setting to wait for feedback. Created attachment 175703 [details] attachment-3247666-0.html I could not save it even after stopping recording, I then tried ‘create copy from current image’ and saved it. Now I can save the new one old one is still not happening On Sun, 10 Nov 2024 at 2:36 PM, Halla Rempt <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=496018 > > Halla Rempt <halla@valdyas.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > CC| |halla@valdyas.org > > --- Comment #2 from Halla Rempt <halla@valdyas.org> --- > Setting to wait for feedback. > > -- > You are receiving this mail because: > You reported the bug. 🐛🧹 Thanks for your comment! Automatically switching the status to REPORTED so the team can perform further triage. In the future you may also do this yourself when providing needed information. Hi, Chris! Do you remember what was the dialog that appeared when you tried to save? Did it let you choose between the three options: save without waiting, don't save and cancel operation? PS: Do you also remember what you did before Krita refused to save? Did you have any clone layers or transform masks in the image? UPD: I forgot about the screenshots. The first question is not actual anymore. The question about "what you did before the issue" is still valid :) Git commit 23882dc7a678a591d5af3c944f9f4f6ca116cd10 by Dmitry Kazakov. Committed on 11/11/2024 at 16:36. Pushed by dkazakov into branch 'master'. Fix a possible saving lockout due to incorrect ownership of the saving mutex Steps to reproduce: 1) Start a very long stroke (that would be calculated for 15 more seconds at least) 2) Press Ctrl+S to initiate saving 3) When asked to wait for the image operation to complete, press "Save without waiting" 4) When the next waiting dialog appears, press "Cancel" (you should be very quick) Before this patch, the document will fall into a locked up state, when no saving is possible. It happened because of a 'return' expression after the saving mutex has been taken. This patch changes the ownership of this mutex to a unique_lock, so returns and asserts will no longer cause a complete lockout. This dialog could have been triggered by the autosave operation. If the used "accidentially" clicked "Cancel" button, then the document could end up in a locked up state as well. M +72 -27 libs/ui/KisDocument.cpp M +2 -2 libs/ui/KisDocument.h M +3 -2 libs/ui/KisImportExportUtils.h https://invent.kde.org/graphics/krita/-/commit/23882dc7a678a591d5af3c944f9f4f6ca116cd10 Git commit 706b558625d79f27cb8f774ea408b1540d08a719 by Dmitry Kazakov. Committed on 11/11/2024 at 16:37. Pushed by dkazakov into branch 'krita/5.2'. Fix a possible saving lockout due to incorrect ownership of the saving mutex Steps to reproduce: 1) Start a very long stroke (that would be calculated for 15 more seconds at least) 2) Press Ctrl+S to initiate saving 3) When asked to wait for the image operation to complete, press "Save without waiting" 4) When the next waiting dialog appears, press "Cancel" (you should be very quick) Before this patch, the document will fall into a locked up state, when no saving is possible. It happened because of a 'return' expression after the saving mutex has been taken. This patch changes the ownership of this mutex to a unique_lock, so returns and asserts will no longer cause a complete lockout. This dialog could have been triggered by the autosave operation. If the used "accidentially" clicked "Cancel" button, then the document could end up in a locked up state as well. M +72 -27 libs/ui/KisDocument.cpp M +2 -2 libs/ui/KisDocument.h M +3 -2 libs/ui/KisImportExportUtils.h https://invent.kde.org/graphics/krita/-/commit/706b558625d79f27cb8f774ea408b1540d08a719 |