Created attachment 141194 [details] System information from Krita SUMMARY STEPS TO REPRODUCE 1. Create new image 1024x1024 2. Draw some lines on the empty layer (cover majority of the canvas) 3. Ctr+T 3. Warp Mode 3. Set flexibility to 10 3. Start clicking subdivide (on the value around 15+ the crash is happening) OBSERVED RESULT The application is crashing On 4.4.8 subdivision does not cause a crash. EXPECTED RESULT The subdivisions are being added up to 30. Software contine working. SOFTWARE/OS VERSIONS System information in attached file. ADDITIONAL INFORMATION Related thread on krita-artists forum: https://krita-artists.org/t/bug-maybe-pressing-on-value-changing-slider-for-flexibility-on-warp-transform-does-nothing/28336
I can confirm this for the Aug 31 5.1.0-prealpha (git c3e53df) appimage on Debian 10. It does not happen with the 4.4.8 appimage hence regression. The crash only happens if Anchor Strength is Strong (Rigid). If Flexibility is 10.0 then there is a crash at about 12 subdivisions. If Flexibility is 5.0, there is no crash. I haven't tried to track down a 'critical' Subdivide value but it seems to be between 5.0 and 7.0. With the crash, the terminal output says: ASSERT (krita): "hash != KeyTraits::NullHash" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/image/3rdparty/lock_free_map/leapfrog.h, line 161 Aborted If I have Flexibility = 5.0 and run the Subdivision up to 30, then I can set Flexibility to 10.0 and run the Subdivision up and down over the entire range with no crash. I haven't investigated the many possibilities of new image, new transform, new settings etc that could indicate a detailed pattern of cause/effect.
Weird... I followed the instructions with my build of Krita, hoping to get a backtrace, but I don't have a crash, which was built with CRASH_ON_SAFE_ASSERTS. I did reproduce it with the 5.0 beta1 appimage, which should actually recover from the assert: #ifdef SANITY_CHECK KIS_ASSERT_RECOVER_NOOP(table); KIS_ASSERT_RECOVER_NOOP(hash != KeyTraits::NullHash); #endif // SANITY_CHECK Dmitry, can you both check why Krita halts on these asserts, and why the assert happens there?
The assert here happens because the transform tool tries to access tiles with coordinates above 2000000. And that might happen because the transformation formula becomes unstable. It didn't happen before because 4.4.8 didn't have in-stack preview.
Git commit ab009c757d8968f5f193d96a0ab78e9475fcbeee by Dmitry Kazakov. Committed on 24/11/2021 at 14:10. Pushed by dkazakov into branch 'master'. Fix assert in rigid-warp-transform with flecibility set to 10.0 The assert happened becasuse the transofrmation tried to read from infinite source position, which is not really a supported feature. Now PaintDevicePolygonOp checks is the transformation is not too small before actually performing it. M +20 -0 libs/image/kis_four_point_interpolator_backward.h M +37 -20 libs/image/kis_grid_interpolation_tools.h https://invent.kde.org/graphics/krita/commit/ab009c757d8968f5f193d96a0ab78e9475fcbeee
Git commit 3adfe39f2da824110c89ca083ae92b17acddae3f by Dmitry Kazakov. Committed on 25/11/2021 at 11:36. Pushed by dkazakov into branch 'master'. Make hashing function in the tile manager more robust In same rare cases (which are officially bugs and must be fixed), the algorithms may request tiles from the tile data manager from non-addressable range, which is above +/- 2 million pixels. The tile manager cannot address anything there, so before the patch it just crashed with an assert. This patch add a fallback solution: the such a case, the tile manager will just return an empty detached tile to the caller. This tile will be destroyed via a shared pointer when the caller is done processing it. M +58 -9 libs/image/tiles3/kis_tile_hash_table2.h https://invent.kde.org/graphics/krita/commit/3adfe39f2da824110c89ca083ae92b17acddae3f
Git commit 634c4790017dee4c4d416b95ea783d00d692b7f1 by Dmitry Kazakov. Committed on 25/11/2021 at 11:36. Pushed by dkazakov into branch 'master'. Make backward interpoilation validity check more robust When estimating the area under the polygon we shoudl care about both triangles, ABC and BCD. Otherwise it can declare correct polygons as invalid. M +3 -5 libs/image/kis_four_point_interpolator_backward.h https://invent.kde.org/graphics/krita/commit/634c4790017dee4c4d416b95ea783d00d692b7f1
Git commit 0b5f887f4ccaab498ea97fef0d91e53aeac2d790 by Dmitry Kazakov. Committed on 25/11/2021 at 11:37. Pushed by dkazakov into branch 'krita/5.0'. Fix assert in rigid-warp-transform with flecibility set to 10.0 The assert happened becasuse the transofrmation tried to read from infinite source position, which is not really a supported feature. Now PaintDevicePolygonOp checks is the transformation is not too small before actually performing it. M +20 -0 libs/image/kis_four_point_interpolator_backward.h M +37 -20 libs/image/kis_grid_interpolation_tools.h https://invent.kde.org/graphics/krita/commit/0b5f887f4ccaab498ea97fef0d91e53aeac2d790
Git commit 2dabf2cdf986165640639a0894dc6abc7f943471 by Dmitry Kazakov. Committed on 25/11/2021 at 11:37. Pushed by dkazakov into branch 'krita/5.0'. Make backward interpoilation validity check more robust When estimating the area under the polygon we shoudl care about both triangles, ABC and BCD. Otherwise it can declare correct polygons as invalid. M +3 -5 libs/image/kis_four_point_interpolator_backward.h https://invent.kde.org/graphics/krita/commit/2dabf2cdf986165640639a0894dc6abc7f943471
Git commit 6a064b19982dba601df8fd61ec7beb8d39455395 by Dmitry Kazakov. Committed on 25/11/2021 at 11:37. Pushed by dkazakov into branch 'krita/5.0'. Make hashing function in the tile manager more robust In same rare cases (which are officially bugs and must be fixed), the algorithms may request tiles from the tile data manager from non-addressable range, which is above +/- 2 million pixels. The tile manager cannot address anything there, so before the patch it just crashed with an assert. This patch add a fallback solution: the such a case, the tile manager will just return an empty detached tile to the caller. This tile will be destroyed via a shared pointer when the caller is done processing it. M +58 -9 libs/image/tiles3/kis_tile_hash_table2.h https://invent.kde.org/graphics/krita/commit/6a064b19982dba601df8fd61ec7beb8d39455395
*** Bug 443189 has been marked as a duplicate of this bug. ***