Bug 402535 - Krita memory leaks or endless loop when using freehand brush with perspective assistant
Summary: Krita memory leaks or endless loop when using freehand brush with perspective...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tool/Assistants (show other bugs)
Version: 4.1.7
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-24 17:17 UTC by genosimple
Modified: 2019-01-07 11:10 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description genosimple 2018-12-24 17:17:55 UTC
This bug leads to UI unresponsiveness after short time under certain conditions. Task manager indicates huge memory usage(>4GiB)


STEPS TO REPRODUCE
1. create a new image(i used 64x64 pixel with other settings at default values)
2. Add a couple of connected perspective assistants to canvas
3. Choose freehand draw tool, turn "use assistant" tool option on.
4. I used simple pixel art brushes to trigger the bug, might work with others as well
5. Draw several lines using assistant with the freehand brush.

OBSERVED RESULT
The bug is not triggered immediately, but after some short time(a couple seconds in my case) you will notice UI becoming sluggish or unresponsive, and the memory usage stat in the Task Manager will shoot through the roof.

EXPECTED RESULT
is obvious

SOFTWARE/OS VERSIONS
Windows: 7 x64

ADDITIONAL INFORMATION
Version Krita 4.04 doesnt seem to have the bug
Comment 1 Scott Petrovic 2019-01-02 14:20:59 UTC
I tested this out and not sure if I can reproduce. The application does slow down with two perspective assistants, but I don't see any type of memory leak, endless loop, or the UI being unresponsive. It only seems to slow down on my machine with things like canvas zooming, panning, or rotating. Basic painting/drawing on the canvas appears to be ok.

I am on Windows 10 x64 (OpenGL on). I am not sure if my slow down is the same thing as the (much more serious) issues that the original bug reporter is having.
Comment 2 genosimple 2019-01-03 19:55:26 UTC
Hi,

i created a youtube video with me showing the bug: https://www.youtube.com/watch?v=EEmA1dGu3sU . It is very reliable to reproduce, just requires some specific setup to happen.

I hope it helps a bit
Comment 3 Scott Petrovic 2019-01-04 14:43:14 UTC
Thanks for the video. There is something definitely odd going on.

I am on Windows 10 and a slightly different version. That is definitely a memory leak going on, but I am not sure why.

Can you see if it happens with the latest nightly build. The nightly build has 4.2 which has quite a bit more work on it (and what I am currently using). I don't see that happening on my Windows 10 box, so maybe the fix will be in the newest version.

https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/

Last Successful Artifacts has the builds. The second link is the installer and the third link is the portable version. Let us know what you find out.
Comment 4 genosimple 2019-01-04 15:49:49 UTC
The last nightly build also crashes after the procedure with exception (0x40000015) somewhere in module QtCore.dll. 
Other abnormal behaviour (memory leak, ui freeze) still happens just before the crash
Comment 5 Halla Rempt 2019-01-06 11:05:51 UTC
Could you please attach the crash log? See https://docs.krita.org/en/reference_manual/dr_minw_debugger.html
Comment 6 genosimple 2019-01-06 14:40:46 UTC
Trying to debug it right now

pausing at the moment of big memory allocation gives this

https://imgur.com/a/6zEhGLa

Notice big numbers in col/row function arguments
Help from irc suggested that assistant math might be at fault, as it generates huge position values for brush paint operations
Comment 7 genosimple 2019-01-06 14:44:05 UTC
my kritacrush.log only contains info from "Error occurred on Tuesday, April 17, 2018 at 12:08:01."

so im not sure this would be relevant
Comment 8 genosimple 2019-01-06 19:30:52 UTC
And i'm stuck here

https://imgur.com/a/6zEhGLa

I traced the problem to this function: KisToolFreehandHelper::paint(KisPaintInformation&), which under some circumstances calls paintLine(const KisPaintInformation& from, const KisPaintInformation& to) on line 595 where to.pos() is {NaN, NaN}. This in turn, causes all the other above mentioned symptoms.

I also found more reliable way to trigger this one. Create a "box" from perspective assistants as in the video above, then start drawing with brush just outside of the box. This triggers the bug instantly almost always during my testing 

All of this was done with v4.1.7 tag from git.
Comment 9 genosimple 2019-01-07 00:04:25 UTC
I posted a diff with a fix: https://phabricator.kde.org/D18024
Comment 10 Bug Janitor Service 2019-01-07 03:44:26 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 11 Halla Rempt 2019-01-07 11:10:51 UTC
Git commit 7225997b8e8ee70a252941e308908dded447fd2c by Boudewijn Rempt, on behalf of Pavel Belski.
Committed on 07/01/2019 at 11:10.
Pushed by rempt into branch 'master'.

M  +7    -1    libs/ui/kis_painting_assistants_decoration.cpp

https://commits.kde.org/krita/7225997b8e8ee70a252941e308908dded447fd2c