In a new document, switch to the reference image tool, then right-click->copy and right-click->paste. This triggers an assert: ASSERT (krita): "!qimage.isNull()" in file C:/Packaging/workspace/Krita_Nightly_Windows_Build/krita/libs/ui/kis_clipboard.cc, line 397 There seems to be two issues here: - Performing a copy action with no reference image selected copies something invalid (I really think the action should just be disabled.) - Pasting with some potentially malformed bitmap data in the clipboard triggers the assert. (nightly caf9f20fd9)
Let's see what we ran into today...
> There seems to be two issues here: > > - Performing a copy action with no reference image selected copies something > invalid (I really think the action should just be disabled.) Currently (after my patch for bug 452810), reference tool just copies whatever Krita offers it (exactly like Edit->Copy) which seems to be the layer itself. We *can* make the cut/copy actions in Reference Image’s context menu be grayed out when nothing is selected. This seems like a trivial problem, if we create a separate action and delegate it to the global “edit_copy” action.
> copies whatever Krita offers it (exactly like Edit->Copy) which seems to be the layer itself So, does this mean if the layer is completely empty Krita puts an empty bitmap into the clipboard?
> So, does this mean if the layer is completely empty Krita puts an empty bitmap into the clipboard? Not entirely sure, but we do get this warning when the layer is empty and the system clipboard doesn't register anything: serializeToByteArray():: Could not export to our native format
Cannot reproduce with a792621925. Doing the specified steps result in a blank KisNode being pasted as a reference KRA.
I can still reproduce the crash on my llvm-mingw build with 6dc6474c5a92652c5e994f2535b8ca3595672f98 as base
I need then a stacktrace *plus* a debug log with `krita.ui.debug = true` in the `QT_LOGGING_RULES` environment variable.
Created attachment 148945 [details] log + backtrace
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.
> - Performing a copy action with no reference image selected copies something invalid (I really think the action should just be disabled.) This action copies and pastes the current layer as a KRA. > - Pasting with some potentially malformed bitmap data in the clipboard triggers the assert. Do you have any application in your system that clears the clipboard every now and then? Perhaps a password manager?
> Do you have any application in your system that clears the clipboard every > now and then? Perhaps a password manager? No... But I might know why you can't reproduce it... My new documents have two layers: one background fill and one empty layer. If your new document has one background layer only then perhaps it may not crash?
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1452
> If your new document has one background layer only then perhaps it may not crash? No, the assert you're hitting means the clipboard told us that it has an image, but the retrieval from QMimeData yielded nothing. Only way that can happen (afaik) is if the clipboard was zeroed out between the check and the actual retrieval. I've tried to work around it by retrieving the image first and then doing all checks against its existence.
Created attachment 149029 [details] InsideClipboard screenshot This is what NirSoft InsideClipboard says about the clipboard after the copy step, if that helps.
I also got these lines from the Krita console output when loading InsideClipboard: serializeToByteArray():: Could not export to our native format serializeToByteArray():: Could not export to our native format serializeToByteArray():: Could not export to our native format
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1459
Git commit 4b822c6e6fca1cf4d9cb378474c05f0c3ab18bbd by L. E. Segovia. Committed on 31/05/2022 at 14:47. Pushed by lsegovia into branch 'master'. KisClipboard: work around possible race condition It seems possible that the underlying clipboard mimedata has its image data zeroed before we retrieve it. M +18 -12 libs/ui/kis_clipboard.cc https://invent.kde.org/graphics/krita/commit/4b822c6e6fca1cf4d9cb378474c05f0c3ab18bbd