Created attachment 125097 [details] error message capture SUMMARY git 0a0738b STEPS TO REPRODUCE 1. Make more than 2 layers and draw something on one of them. 2. Select the drawing with selection tool. 3. Select any empty layer in the layers docker, and click it with liquify tool. 3. Select the layer that has the drawing, and try to transform it with liquify tool. OBSERVED RESULT The projection of the original drawing stays as you edit it. And when you try to confirm(apply) the result, krita crashes. Additionally, after you've done this more than one time in the document, krita shows an error message(safe assert) when you try to save the document. EXPECTED RESULT It should be editable and shouldn't crash. SOFTWARE/OS VERSIONS Windows: Win7 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 125121 [details] good liquify result Shouldn't this be marked as a Crash bug? Using the 4.3.0 prealpha appimage (git 0a0738b) I get slightly different (but still incorrect results) and a crash on saving. As follows: Steps to reproduce [and Observed results] 1. Make two layers and draw something on one of them. 2. Make a rectangular selection around the drawing. 3. Select the empty layer, click it with the Liquify Transform tool. [Get a warning: Cannot transform empty layer.] 4. Select the layer with the drawing and use the Liquify transform tool. [On the first stroke, the selection outline is removed and there is no effect on the drawing.] [On further strokes, a liquify action is performed on the painted pixels.] 5. Liquify/drag pixels from inside the selection to outside the selection. [This works with some interesting 'sector sweeping' effects but there is quite a bit of lag.] 6. Press Return to confirm/apply the transform. [The projected screen image returns to the original drawing.] [After a wait of about three seconds, the following is observed: ...] [The selection outline returns and has it's outline dragged out in accordance with the liquify actions.] [The Overview and the Layer thunbnail both show the liquified result.] [Turning layers on and off does not give a liquified result on-screen.] [If the drawing layer is turned off, the original drawing is still on-screen.] 7. Try to look at the Help - system info window [It shows a Safe Assert due to Transform] 9. Close the System info window with its Ok button. [Crash] 13 Jan 2020 21:43:26 +0000: Created image "Unnamed", 3508 * 2480 pixels, 300 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 2 13 Jan 2020 21:43:45 +0000: SAFE ASSERT (krita): "m_savedTransformArgs" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/plugins/tools/tool_transform2/strokes/transform_stroke_strategy.cpp, line 400 13 Jan 2020 21:49:26 +0000: Autosaving: /home/adminahab/krita-14594-document_0-autosave.kra 13 Jan 2020 21:49:27 +0000: ASSERT (krita): "!rhs.m_d->disableUIUpdateSignals" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/image/kis_image.cc, line 461 Note the Autosaving action. Running krita again, there was no offer to load the autosaved file because it didn't exist. Turning Autosave off and repeating the Steps, I got a crash at Step 6. 13 Jan 2020 21:57:01 +0000: Created image "Unnamed", 3508 * 2480 pixels, 300 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 2 13 Jan 2020 21:57:19 +0000: SAFE ASSERT (krita): "m_savedTransformArgs" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/plugins/tools/tool_transform2/strokes/transform_stroke_strategy.cpp, line 400 13 Jan 2020 21:57:50 +0000: ASSERT (krita): "row < 0x7FFF && col < 0x7FFF" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/image/tiles3/kis_tile_hash_table2.h, line 133 Repeating this process in a freshly started krita (with Autosave still turned off), the observed results were repeated and at Step 7, the Safe Assert was there: 14 Jan 2020 13:37:06 +0000: Created image "Unnamed", 3508 * 2480 pixels, 300 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 2 14 Jan 2020 13:38:09 +0000: SAFE ASSERT (krita): "m_savedTransformArgs" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/plugins/tools/tool_transform2/strokes/transform_stroke_strategy.cpp, line 400 Then Save the document and there was a crash with no file saved: 14 Jan 2020 13:48:49 +0000: Saving Document as /home/adminahab/CONFIG/dump/Desktop/tue-liquify-1.kra (mime: application/x-krita). 3508 * 2480 pixels, 5 layers. 101 frames, 24 framerate. Export configuration: No configuration 14 Jan 2020 13:48:49 +0000: ASSERT (krita): "!rhs.m_d->disableUIUpdateSignals" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/image/kis_image.cc, line 461 KRITA DID NOT CLOSE CORRECTLY Restarted krita and repeated the process with a variation: At Step 3. Click the empty layer with the Free Transform Tool At Step 4. Select the drawing layer and click with the Liquify Transform Tool. [The Liquify transform works on the drawing as before.] At Step 5. [As before.] At Step 6. [Everything works with no problems.] The image can be saved with no crashing and is attached as tue-liquify-4.kra
Setting to CONFIRMED
Yes, this is a crash bug.
Backtrace: Thread 1 (Thread 0x7f8133495800 (LWP 11394)): [KCrash Handler] #6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #7 0x00007f812dc4f801 in __GI_abort () at abort.c:79 #8 0x00007f812e67959b in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x00007f81300e918a in kis_assert_common (assertion=<optimized out>, file=<optimized out>, line=<optimized out>, throwException=<optimized out>, isIgnorable=<optimized out>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:61 #10 0x00007f8130a5f1f9 in KisImage::copyFromImageImpl (this=<optimized out>, rhs=..., policy=<optimized out>) at /usr/include/c++/9/bits/atomic_base.h:413 #11 0x00007f8130a5fdc3 in KisImage::KisImage (this=0x55f788635ad0, rhs=..., undoStore=<optimized out>, exactCopy=<optimized out>) at /home/boud/dev/4.3/libs/image/kis_image.cc:483 #12 0x00007f8130a5fe86 in KisImage::clone (this=0x55f779c7b660, exactCopy=exactCopy@entry=true) at /home/boud/dev/4.3/libs/image/kis_image.cc:355 #13 0x00007f8132148418 in KisDocument::copyFromDocumentImpl (this=0x55f78421f0e0, rhs=..., policy=KisDocument::CONSTRUCT) at /home/boud/dev/4.3/libs/ui/KisDocument.cpp:906 #14 0x00007f8132148c5a in KisDocument::KisDocument (this=0x55f78421f0e0, rhs=...) at /home/boud/dev/4.3/libs/ui/KisDocument.cpp:536 #15 0x00007f8132148e58 in KisDocument::lockAndCloneForSaving (this=0x7f810c006090) at /home/boud/dev/4.3/libs/ui/KisDocument.cpp:855 #16 0x00007f8132149b1d in KisDocument::initiateSavingInBackground (this=0x7f810c006090, actionName=..., receiverObject=0x7f810c006090, receiverMethod=0x7f8132c1d8f8 "1slotCompleteSavingDocument(KritaUtils::ExportFileJob, KisImportExportErrorCode ,QString)", job=..., exportConfiguration=..., optionalClonedDocument=...) at /home/boud/dev/4.3/libs/ui/KisDocument.cpp:990 #17 0x00007f8132149e24 in KisDocument::initiateSavingInBackground (this=<optimized out>, actionName=..., receiverObject=<optimized out>, receiverMethod=<optimized out>, job=..., exportConfiguration=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60 #18 0x00007f813214a032 in KisDocument::exportDocumentImpl (this=0x7f810c006090, job=..., exportConfiguration=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1051 #19 0x00007f813214b34f in KisDocument::saveAs (this=this@entry=0x7f810c006090, _url=..., mimeType=..., showWarnings=showWarnings@entry=true, exportConfiguration=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60 #20 0x00007f8132171df3 in KisMainWindow::saveDocument (this=0x55f7803b7980, document=0x7f810c006090, saveas=<optimized out>, isExporting=false) at /home/boud/dev/4.3/libs/global/kis_shared_ptr.h:82 #21 0x00007f8132172e33 in KisMainWindow::slotFileSaveAs (this=0x55f7803b7980) at /usr/include/c++/9/bits/atomic_base.h:413 #22 0x00007f8132179a37 in KisMainWindow::qt_static_metacall (_o=0x55f7803b7980, _c=<optimized out>, _id=<optimized out>, _a=0x7ffd31fa7510) at /home/boud/dev/b-4.3/libs/ui/kritaui_autogen/include/moc_KisMainWindow.cpp:380 #23 0x00007f812e8c7dc9 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #24 0x00007f812f7703a2 in QAction::triggered(bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #25 0x00007f812f772a0c in QAction::activate(QAction::ActionEvent) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #26 0x00007f812f8ed2ec in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #27 0x00007f812f8f48db in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #28 0x00007f812f8f6eda in QMenu::keyPressEvent(QKeyEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #29 0x00007f812f7b8037 in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #30 0x00007f812f8f792b in QMenu::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #31 0x00007f812f7768bc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #32 0x00007f812f77eae2 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #33 0x00007f81321355a9 in KisApplication::notify (this=<optimized out>, receiver=0x55f783d600d0, event=0x7ffd31fa7e80) at /home/boud/dev/4.3/libs/ui/KisApplication.cpp:680 #34 0x00007f812e88cdb8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #35 0x00007f812f7d4d05 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #36 0x00007f812f7768bc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #37 0x00007f812f77dac0 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #38 0x00007f81321355a9 in KisApplication::notify (this=<optimized out>, receiver=0x55f7873dcb70, event=0x7ffd31fa7e80) at /home/boud/dev/4.3/libs/ui/KisApplication.cpp:680 #39 0x00007f812e88cdb8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #40 0x00007f812ee8573b in QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #41 0x00007f812ee8a0a5 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #42 0x00007f812ee6301b in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #43 0x00007f811ee0bc8a in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #44 0x00007f8125e6f417 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #45 0x00007f8125e6f650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #46 0x00007f8125e6f6dc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #47 0x00007f812e8ec0bc in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #48 0x00007f812e88b63a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #49 0x00007f812e894db0 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #50 0x000055f775416b47 in main (argc=<optimized out>, argv=0x7ffd31fa84a8) at /home/boud/dev/4.3/krita/main.cc:593 [Inferior 1 (process 11394) detached]
I need someone else to confirm this is not happening anymore, as I cannot reproduce at all on current master (c66a55f65edaf0) and current 4.3 stable branch. Tested on macos, linux and windows.
I can't build from the master but I just tested with built appimages: The released 4.3.0 beta-1 behaves properly with no Asserts and it shows correct screen contents after applying the liquify transform. The image can be saved and opened. The 29 May 4.3.0 beta-2 (git f6ee764) shows all the incorrect screen presentations as previously noted but no Asserts. However, it crashes on saving. ========================================================================== 30 May 2020 09:09:47 +0100: Saving Document as /home/adminahab/CONFIG/dump/Pictures/liq-1.kra (mime: application/x-krita). 1600 * 1200 pixels, 4 layers. 101 frames, 24 framerate. Export configuration: No configuration 30 May 2020 09:09:47 +0100: ASSERT (krita): "!rhs.m_d->disableUIUpdateSignals" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/image/kis_image.cc, line 463 KRITA DID NOT CLOSE CORRECTLY ========================================================================== It can open the file produced by the 4.3.0 beta-1 with no problem. The 29 May 5.0.0 prealpha (git e09e595) has the same behaviour as the 29 May 4.3.0 beta-2 and crashes on saving.
Ivan, since the issue is an assert on saving, are you sure you're building with asserts enabled?
It seems this still happens in git c6aeea5.
Okay, if ivan cannot reproduce this at all, someone else will have to look into it.
I'm wondering whether this might not have accidentally be fixed by commit c6fed882eaef18afc8bf747b23b788f799f37b69 Author: Dmitry Kazakov <dimula73@gmail.com> Date: Thu Jun 11 21:50:28 2020 +0300 Fix Liquify Transform to avoid changing the image when no transform done BUG:416471 Could someone check with the latest nightly build from master?
I've tried this with the 12 June 5.0.0-prealpha (git 4cb6020) appimage and with the 12 June 4.3.0-prealpha (git g4cb6020) portable .zip running on Windows 10. I was able to crash each of them only once and could not replicate the crash despite several attempts and speculative variations on the Steps. For the appimage and the portable .zip, the crash happened after finalising the liquify action. When the crash didn't happen there was no problem Saving a .kra file. For both of them the log entry after the crash was identical (except for the time and the file location): ========================================================================= 12 Jun 2020 16:33:50 +0200: ASSERT (krita): "row < 0x7FFF && col < 0x7FFF" in file C:\Packaging\workspace\Krita_Nightly_Windows_Build\krita\libs\image\tiles3\kis_tile_hash_table2.h, line 133 ========================================================================= I'll have another look at it later but for now, it all seems to work apart from those strange rare crashes.
Hi, all! Could you please check the current nightlies for master? I cannot reproduce the crashes anymore, neither on apply nor on saving the document. PS: 4.x branch is done now, so I don't think we'll have a fix for it.
(In reply to Dmitry Kazakov from comment #12) > Hi, all! > > Could you please check the current nightlies for master? I cannot reproduce > the crashes anymore, neither on apply nor on saving the document. > > PS: > 4.x branch is done now, so I don't think we'll have a fix for it. Yes, it seems it's fixed in the latest 5.0 alpha nightly branch.
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.
Testing with the July 19 5.0.0-prealpha (git c81ba5b) appimage on Debian 10: There are no crashes or safe asserts when testing as before. The transform of an empty layer does not give a warning about being unable to tranform an empty layer. Instead, it places a content bounding box around the selection (which become invisible) and tranform actions will transform the selection outline. While this is happening, you can't see the selection outline but it returns when the transform is Applied.
Hi, Ahab! Do you consider this selection behavior as a bug or not? I'm not sure how it should behave in the ideal case ;)
Hi Dmitry :) The correct/ideal behaviour would be to give the usual warning that the tranform can't be done on an empty layer. I did think it was 'fun' that you can transform a selection like that but there's already the Select -> Edit Selection facility which uses the transform tool with the selection shown as a mask. If this current behaviour is left in, it could easily confuse people, leading to work errors and so my personal opinion is that it should be removed and the 'no transform on an empty layer' warning should be shown.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!