Bug 453190

Summary: Copy then paste in reference image tool with nothing selected will crash
Product: [Applications] krita Reporter: Alvin Wong <alvin>
Component: Tools/Reference ImagesAssignee: amyspark <amy>
Status: RESOLVED FIXED    
Severity: normal CC: amy, shzam
Priority: NOR    
Version First Reported In: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: log + backtrace
InsideClipboard screenshot

Description Alvin Wong 2022-04-29 11:27:08 UTC
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)
Comment 1 amyspark 2022-04-29 11:58:51 UTC
Let's see what we ran into today...
Comment 2 sh_zam 2022-04-29 12:54:49 UTC
> 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.
Comment 3 Alvin Wong 2022-04-29 12:59:07 UTC
> 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?
Comment 4 sh_zam 2022-04-29 13:49:01 UTC
> 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
Comment 5 amyspark 2022-05-16 21:04:56 UTC
Cannot reproduce with a792621925. Doing the specified steps result in a blank KisNode being pasted as a reference KRA.
Comment 6 Alvin Wong 2022-05-18 09:26:24 UTC
I can still reproduce the crash on my llvm-mingw build with 6dc6474c5a92652c5e994f2535b8ca3595672f98 as base
Comment 7 amyspark 2022-05-18 12:29:26 UTC
I need then a stacktrace *plus* a debug log with `krita.ui.debug = true` in the `QT_LOGGING_RULES` environment variable.
Comment 8 Alvin Wong 2022-05-18 13:01:58 UTC
Created attachment 148945 [details]
log + backtrace
Comment 9 Bug Janitor Service 2022-05-19 04:35:34 UTC
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.
Comment 10 amyspark 2022-05-20 15:58:24 UTC
> - 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?
Comment 11 Alvin Wong 2022-05-20 16:09:59 UTC
> 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?
Comment 12 Bug Janitor Service 2022-05-20 16:12:41 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1452
Comment 13 amyspark 2022-05-20 16:15:36 UTC
> 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.
Comment 14 Alvin Wong 2022-05-20 17:07:37 UTC
Created attachment 149029 [details]
InsideClipboard screenshot

This is what NirSoft InsideClipboard says about the clipboard after the copy step, if that helps.
Comment 15 Alvin Wong 2022-05-20 17:11:35 UTC
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
Comment 16 Bug Janitor Service 2022-05-26 00:47:21 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1459
Comment 17 amyspark 2022-05-31 14:48:19 UTC
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