Bug 456778 - pasting a not properly copied web image crashes krita
Summary: pasting a not properly copied web image crashes krita
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Unclassified
Component: General (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR crash
Target Milestone: ---
Assignee: amyspark
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-15 22:39 UTC by til.schmitter
Modified: 2022-07-19 23:48 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description til.schmitter 2022-07-15 22:39:55 UTC
5.2.0 prealpha git a40c361 (i just updated bc it was broken in the previous prealpha version i had from a few weeks ago as well)

STEPS TO REPRODUCE
1. configure krita>general>miscellaneous>when pasting from other applications: either local copy or sRGB bitmap 
(download works without crash but takes very long)
2. copy a high res image from your browser (i used this: https://cdn.discordapp.com/attachments/499274560089096202/997602360618655864/IMG_20220715_173225.jpg
2736x3648 photo)
3. paste with ctrl+V or as reference onto a canvas

THIS STOPS HAPPENNING AFTER WAITING A BIT BEFORE PASTING!
i feel like the image was so big that it took a while to copy into memory. might be a windows issue in that case..?

SYSTEM INFO
OS: win10
CPU: i7-6700
24GB RAM
GPU: AMD RX5700XT

CRASH LOG
my crash log is quite long bc it crashed a few times so here's a copy of the part i think might be relevant:

Krita Version: 5.2.0-prealpha (git a40c361), Qt version compiled: 5.12.12, loaded: 5.12.12. Process ID: 11412
-- -- -- -- -- -- -- --
15 Jul 2022 23:10:49 +0200: Style: fusion. Available styles: windowsvista, Windows, Fusion
15 Jul 2022 23:11:00 +0200: Database is up to date. Version: 0.0.17, created by Krita 5.1.0-beta2, at Sa Jun 25 23:04:40 2022
15 Jul 2022 23:11:06 +0200: Could not retrieve md5 for resource paintoppresets/Special_dyna_dots.kpp
15 Jul 2022 23:11:07 +0200: Non-store package - creating updater
15 Jul 2022 23:11:44 +0200: Created image "Unnamed", 2736 * 3648 pixels, 300 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 1
15 Jul 2022 23:11:54 +0200: ASSERT (krita): "!qimage.isNull()" in file C:/Packaging/workspace/Krita_Nightly_Windows_Build/krita/libs/ui/kis_clipboard.cc, line 462
================================================================================
(...)
krita.exe caused a Breakpoint at location 00007FFD7969D662 in module KERNELBASE.dll.
Comment 1 til.schmitter 2022-07-15 23:12:27 UTC
oh i guess this part from the crash log should also help

krita.exe caused a Breakpoint at location 00007FFD7969D662 in module KERNELBASE.dll.

AddrPC           Params
00007FFD7969D662 000001A1934A6610 0000000000000086 00007FFD3CEF7C00  KERNELBASE.dll!wil::details::DebugBreak+0x2
00007FFD3B0B481A 00007FFD3CEF7AEE 00000000000001CE 00007FFD3B60A3C0  Qt5Core.dll!qt_message_fatal+0xa
00007FFD3B0B58AF 0000000A684FB4B0 0000000A00000000 000001A19239E5C8  Qt5Core.dll!QMessageLogger::fatal+0x85
00007FFD58C92F6D 0000000000000000 0000000A80000000 0000000000000003  libkritaglobal.dll!kis_assert_common+0x54d
00007FFD58C930D1 000001A1F470B640 0000000A684FB8B0 0000000A684FB980  libkritaglobal.dll!kis_assert_exception+0x11
00007FFD3CA0F534 000001A1870CE560 000001A1901BED10 000001A192600310  libkritaui.dll!KisClipboard::clipFromBoardContents+0xd4
00007FFD3CA0E0CC 00007FFD3D1301C8 0000000A00000000 000001A185F8CDF0  libkritaui.dll!KisClipboard::clip+0x5bc
00007FFD3CD055EB 0000000000000000 00007FFD794DF05B 000001A1933D99D8  libkritaui.dll!KisPasteActionFactory::run+0x135b
00007FFD3CAFAD96 00007FFD3B60B038 0000000000000001 0000000000000000  libkritaui.dll!KisSelectionManager::paste+0x76
(...)
Comment 2 amyspark 2022-07-15 23:26:50 UTC
> i feel like the image was so big that it took a while to copy into memory. might be a windows issue in that case..?

Indeed. The issue here is that Qt's reporting an image exists in the clipboard (probably based on the mimetypes of the clipboard data) yet the bitmap's irretrievable by the time KisClipboard attempts to read it. The assertion your log and stacktrace refer to is *exactly* this check.

Can you reliably reproduce it with that image? And were you able to test it from other sources? I mean particularly Chromium or d&d from the Explorer.
Comment 3 til.schmitter 2022-07-16 10:10:19 UTC
i was reliably able to reproduce it with this image and also with another image of the same dimensions. did this with edge browser. I'll test the rest in a few days because I'm not at my desktop this weekend. I'll try with my laptop asap though.
Comment 4 til.schmitter 2022-07-17 17:59:29 UTC
> And were you able to test it from other sources? I mean particularly Chromium or d&d from the Explorer.

chrome, firefox, edge all show this behavior and crash.
d&d / copy+paste from the explorer works like normal, no crash here.
Comment 5 til.schmitter 2022-07-17 18:05:23 UTC
since we're already on the topic of copy paste issues, idk if this should be a separate bug report, but drag n drop from browsers only works for reference images. drag n drop as a new layer or new document doesn't work and results in the error: "File [filename] does not exist." after downloading the image
Comment 6 amyspark 2022-07-19 23:48:17 UTC
Git commit e747146f1b6e0e425c73ad125793a19411e3017b by L. E. Segovia.
Committed on 19/07/2022 at 23:45.
Pushed by lsegovia into branch 'master'.

KisClipboard: use the correct check for defaulted bitmap pastes

If cbData->hasImage() returns true, but qimage earlier was null, then
the clipboard has an unfinished or corrupt paste data. We'd added the
check for these cases, but I didn't update the default options for
Chromium sources.

M  +1    -1    libs/ui/kis_clipboard.cc

https://invent.kde.org/graphics/krita/commit/e747146f1b6e0e425c73ad125793a19411e3017b
Comment 7 amyspark 2022-07-19 23:48:34 UTC
Git commit b723e0ef184137748f1cec6116e227c87b29f92a by L. E. Segovia.
Committed on 19/07/2022 at 23:47.
Pushed by lsegovia into branch 'krita/5.1'.

KisClipboard: use the correct check for defaulted bitmap pastes

If cbData->hasImage() returns true, but qimage earlier was null, then
the clipboard has an unfinished or corrupt paste data. We'd added the
check for these cases, but I didn't update the default options for
Chromium sources.
(cherry picked from commit e747146f1b6e0e425c73ad125793a19411e3017b)

M  +1    -1    libs/ui/kis_clipboard.cc

https://invent.kde.org/graphics/krita/commit/b723e0ef184137748f1cec6116e227c87b29f92a