Bug 401497 - Document::clone() can trigger an assert
Summary: Document::clone() can trigger an assert
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Scripting (show other bugs)
Version: 4.1.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-28 10:33 UTC by Zlatko Masek
Modified: 2020-05-19 09:48 UTC (History)
2 users (show)

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


Attachments
backtrace (38.81 KB, text/plain)
2018-12-04 07:02 UTC, Anna Medonosova
Details
Python script triggering the issue (471 bytes, text/x-python)
2018-12-04 07:05 UTC, Anna Medonosova
Details
Python script that does not trigger the issue (517 bytes, text/x-python)
2018-12-04 07:05 UTC, Anna Medonosova
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zlatko Masek 2018-11-28 10:33:50 UTC
SUMMARY
While creating a plugin, I've come onto a bug where cloning a document turns off Krita entirely.

STEPS TO REPRODUCE
1. In one of the Python scripts, have self.document = Krita.instance().activeDocument()
2. attempt running new_image = self.document.clone()
3. Krita turns off by itself

OBSERVED RESULT
Krita turns off by itself


EXPECTED RESULT
Document cloned successfully so other operations can be issued on the copy.

SOFTWARE/OS VERSIONS
Windows: 10
MacOS: Not tested
Linux/KDE Plasma: Not tested
(available in About System)
KDE Plasma Version: N/A
KDE Frameworks Version: N/A
Qt Version: Not sure

ADDITIONAL INFORMATION
If additional code requested, I can provide a full buggy plugin code.
Comment 1 Anna Medonosova 2018-12-02 06:50:26 UTC
I am sorry, I cannot reproduce your issue. I tested in Krita 4.1.0 and 4.1.5 Portable 64-bit on Windows 10 with following code run in Scripter:

---------------------------------------------
document = Krita.instance().activeDocument()
new_image = document.clone()

print(new_image.fileName())
---------------------------------------------


I assume that by “Krita turns off by itself” you mean it crashes. Could you please provide a backtrace from the crash? You can find instruction on how to do that at: https://docs.krita.org/en/reference_manual/dr_minw_debugger.html

Could you also please provide a complete script that triggers the issue on your setup?
Comment 2 Zlatko Masek 2018-12-02 10:48:19 UTC
Hi, Anna,

No crash report as far as I can see. It doesn't give the crash dialog at all. I pushed the code to the repo so you can inspect: https://bitbucket.org/zmasek/krita-leaflet/src/master/
The code is still in development, but the line that breaks it is in app.py on line 56.

Thanks
Comment 3 Bug Janitor Service 2018-12-03 03:44:23 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 4 Anna Medonosova 2018-12-04 07:01:48 UTC
Thanks for supplying the whole plugin. I have run it and I can confirm the issue, it is present also on linux in git master.

The python code triggers the following assert:

ASSERT (krita): "!rhs.m_d->projectionUpdatesFilter" in file [..]/src/master/libs/image/kis_image.cc, line 340

How it happens:

1, the plug-in assigns the active document to self.document
2, then it runs self.document.scaleImage() and self.document.crop()
3, while operations from 2 are still running, the plug-in attempts to clone the document with self.document.clone()
4, assert is triggered

I attach a simple script (401497_test.py) based on the plug-in code that reproduces the issue, to simplify testing.

If I call Document::waitForDone() after scaleImage() and crop() calls, the assert is not triggered (demonstrated by 401497_test_nocrash.py).
Comment 5 Anna Medonosova 2018-12-04 07:02:21 UTC
Created attachment 116663 [details]
backtrace
Comment 6 Anna Medonosova 2018-12-04 07:05:06 UTC
Created attachment 116664 [details]
Python script triggering the issue
Comment 7 Anna Medonosova 2018-12-04 07:05:40 UTC
Created attachment 116665 [details]
Python script that does not trigger the issue
Comment 8 Halla Rempt 2020-05-19 09:26:53 UTC
I guess that since the python api is supposed to be synchronous, it's easiest to just add waitForDone in the Document methods where appropriate.
Comment 9 Halla Rempt 2020-05-19 09:48:06 UTC
Git commit 0fa80e364094483bbf3197ed219054609ac38259 by Boudewijn Rempt.
Committed on 19/05/2020 at 09:47.
Pushed by rempt into branch 'master'.

Call waitForDone after starting a background job from a script

And copy the relevant documentation for locking/waiting methods
from KisImage.
(cherry picked from commit c43fa1a7f78afad41d74f4c039bdac704ddcb582)

M  +6    -6    libs/libkis/Document.cpp
M  +29   -14   libs/libkis/Document.h
M  +0    -1    plugins/extensions/pykrita/sip/krita/Document.sip

https://invent.kde.org/graphics/krita/commit/0fa80e364094483bbf3197ed219054609ac38259
Comment 10 Halla Rempt 2020-05-19 09:48:10 UTC
Git commit c43fa1a7f78afad41d74f4c039bdac704ddcb582 by Boudewijn Rempt.
Committed on 19/05/2020 at 09:47.
Pushed by rempt into branch 'krita/4.3'.

Call waitForDone after starting a background job from a script

And copy the relevant documentation for locking/waiting methods
from KisImage.

M  +6    -6    libs/libkis/Document.cpp
M  +29   -14   libs/libkis/Document.h
M  +0    -1    plugins/extensions/pykrita/sip/krita/Document.sip

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