SUMMARY When taking multiple screenshots and pasting each into Krita, it will eventually crash without warning. STEPS TO REPRODUCE 1. Take a screenshot 2. Open Krita -> Create from Clipboard 3. Take another screenshot 4. Paste into Krita 5. Repeat steps 3 and 4 until it crashes OBSERVED RESULT Krita immediately crashes EXPECTED RESULT Screenshot is pasted into Krita with no issues Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 Kernel Version: 5.15.0-69-generic (64-bit) Graphics Platform: X11
The crash is fairly consistent on my machine, it crashes after taking the second screenshot.
I've done a bit of testing on my end. I have Spectacle set as my screenshot manager, and I have 'Capture Entire Desktop' bound to 'PrintScreen'. I've always had issues with Spectacle not sending the screenshot to the clipboard properly (sometimes it sends nothing and needs more than one hit of the hotkey to capture the screen). The problem seems to go away if I launch Spectacle and then use the hotkey. Either way there seems to be an issue when 'nothing' gets pasted into Krita and it crashes.
Hi! The crash is caused because you (or an app) is clearing the clipboard between initiating the document creation and retrieving the image. Can you send us a stacktrace of the crash so I can confirm the issue?
(waiting for reply)
How do I go about doing that? I have Krita installed via a Flatpak in Discover. I'm fairly certain that your explanation is correct. I'm using an older version of Spectacle (22.08.01) that may be the issue. Regardless, Krita shouldn't just crash if there is 'nothing' pasted into it. There definitely should be some way to handle it, at least the user should be prompted about an error and given the option to save.
(In reply to jimbo from comment #5) > Regardless, Krita shouldn't just crash if there is 'nothing' pasted into it. > There definitely should be some way to handle it, at least the user should > be prompted about an error and given the option to save. Qt provides no atomic way to check-and-load an image from the clipboard: either we deserialize the QImage and then check if it's null (paying the cost of the underlying codec upfront, every time there is a clipboard change), or we check the clipboard for hasImage, then we retrieve it on document creation. The latter is what's happening here. Between the hasImage check and the point of retrieval, something in your side is clearing up the clipboard. The assertion validates that there's an image in the clipboard when the document is created, so once that fails, we crash because it's an inconsistent state. > How do I go about doing that? I have Krita installed via a Flatpak in Discover. I believe https://www.figuiere.net/technotes/notes/tn001/ can help; alternatively, since it's easy in your case to reproduce, could you try the 5.1.5 AppImage and repeating the steps you performed?
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
So, I tried getting the flatpak stacktrace but it returns an error when I try to install the sdk. "No remote refs found similar to ‘org.freedesktop.Sdk/x86_64/22.08’". Any idea what I'm doing wrong there? I used the AppImage and it also crashes when pasting the screenshot.
Oh, I forgot to mention that I'm still on 20.04, so that's probably the reason why. I can't upgrade neon as it causes issues on my machine, I'm putting off doing a fresh install until later this year.
I'll see what we can do, then. It'll take me a couple days because I need to sort out my developer environment.
This should be fixed with tonight's nightly builds. Please visit https://krita.org/en/download/krita-desktop/ to get a copy.
you guys are great! Thanks!
Git commit f4f069cbea3dd961aed23e3abbc67460821b2da9 by L. E. Segovia. Committed on 21/04/2023 at 00:40. Pushed by lsegovia into branch 'master'. KisClipboard: remove assert on clipboard being cleared 6399b0203e7c7e8fa6fc40e4fdbe4a72cae2f304 already covers it enough, so it's safe to bail out now. Related: bug 462006, bug 465128 M +5 -1 libs/ui/kis_clipboard.cc https://invent.kde.org/graphics/krita/commit/f4f069cbea3dd961aed23e3abbc67460821b2da9
Git commit d833fcb31161fbaedd738381613960daf9ac5fb7 by L. E. Segovia. Committed on 21/04/2023 at 00:40. Pushed by lsegovia into branch 'krita/5.1'. KisClipboard: remove assert on clipboard being cleared 6399b0203e7c7e8fa6fc40e4fdbe4a72cae2f304 already covers it enough, so it's safe to bail out now. Related: bug 462006, bug 465128 (cherry picked from commit f4f069cbea3dd961aed23e3abbc67460821b2da9) M +5 -1 libs/ui/kis_clipboard.cc https://invent.kde.org/graphics/krita/commit/d833fcb31161fbaedd738381613960daf9ac5fb7