Bug 441826 - Crash when continuously add subdivisions
Summary: Crash when continuously add subdivisions
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Transform (show other bugs)
Version: 5.0.0-beta1
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression
: 443189 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-08-31 18:12 UTC by yetanotherpainter
Modified: 2021-12-16 10:13 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
System information from Krita (2.59 KB, text/plain)
2021-08-31 18:12 UTC, yetanotherpainter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yetanotherpainter 2021-08-31 18:12:12 UTC
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
Comment 1 Ahab Greybeard 2021-09-01 10:04:10 UTC
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.
Comment 2 Halla Rempt 2021-09-01 10:11:11 UTC
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?
Comment 3 Dmitry Kazakov 2021-11-23 16:04:59 UTC
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.
Comment 4 Dmitry Kazakov 2021-11-24 14:10:41 UTC
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
Comment 5 Dmitry Kazakov 2021-11-25 11:36:22 UTC
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
Comment 6 Dmitry Kazakov 2021-11-25 11:36:30 UTC
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
Comment 7 Dmitry Kazakov 2021-11-25 11:42:13 UTC
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
Comment 8 Dmitry Kazakov 2021-11-25 11:42:21 UTC
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
Comment 9 Dmitry Kazakov 2021-11-25 11:42:30 UTC
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
Comment 10 Dmitry Kazakov 2021-12-16 10:13:40 UTC
*** Bug 443189 has been marked as a duplicate of this bug. ***