Created attachment 1640539 [details]
kig file reproducing the problem

Kig file containing a python script.

Fedora cannot fix bugs in upstream code, if you are not even using a Fedora package. The bug is already filed upstream as it should, so closing this bug report.

We can reopen this bug if and when you can reproduce it using a Fedora package (kig >= 19.08.1-3, which ships Python 3 scripting support). Note that we cannot support Python 2 scripting anymore because the Python SIG is aggressively deprecating Python 2.

Looks like this also happens with the kig-19.08.3-1.fc31 package, so I am reopening this, though I am not sure whether I will be able to fix it.

Actually, I realise that it makes no sense in trying to debug this since python scripting seems completely broken upstream... there can even
be NO relation at all between the problem upstream and the crash downstream.  I will try to focus a little bit on the Git sources and see if
I can do something there.

Hence we can close this bug and see what happens.

Then let's close it as an upstream issue. If you can come up with a fix or find one somewhere, please let me know so that I can apply it. Technically, I can even commit it upstream (I have KDE developer access), but would rather not mess too much with projects that I do not maintain upstream. (I am supposed to maintain Kompare and libkomparediff2 and that's it.)

Sorry for inserting text into a CLOSED bug... however it is just to mention that I have a workaround for the bug upstream that "fixes" the python scripting bug.  I am not sure this is a real fix, because of my zero-experience about boost.  However without this fix the upstream git source seems completely broken with respect to the use of scripting, in the sense that we have a crash as soon as a script with one or more arguments is defined!

--------------------------------------------------------------------------------------------------
$ git diff
diff --git a/scripting/python_scripter.cc b/scripting/python_scripter.cc
index 62a7409b..57e09255 100644
--- a/scripting/python_scripter.cc
+++ b/scripting/python_scripter.cc
@@ -531,6 +531,10 @@ ObjectImp* PythonScripter::calc( CompiledPythonScript& script, const Args& args
     };
     tuple argstup( argstuph );
 
+// workaround?
+//
+    Py_INCREF (argstup.ptr());
+
     handle<> reth( PyEval_CallObject( calcfunc.ptr(), argstup.ptr() ) );
 //    object resulto = calcfunc( argstup );
 //    handle<> reth( PyEval_CallObject( calcfunc.ptr(), args ) );
--------------------------------------------------------------------------------------------------

I also added this same comment in the upstream bug report https://bugs.kde.org/show_bug.cgi?id=401512 but I am not very optimistic about a fix at that level very soon, so a possibility could be to incorporate this in the fedora packaging.

This is only a *first step*, however, since the upstream kig seems to be still based on version 2.7 of python whereas kig in fedora has been
patched against version 3 of python.  Using python script with the "fedora" kig version kig-19.08.3-1.fc31.x86_64 causes a crash that *could be* unrelated to the upstream bug.

It makes sense to increment the reference count. I guess the non-workaround version of the fix would also Py_DECREF the reference once it is no longer needed though, in order to avoid leaking memory.

We don't actually apply any patch that is not already in the upstream git master in order to build for Python 3. But it may be that the code compiles against Python 3 but does not run properly. Have you tried building an RPM with your workaround? I can do a build for you to test.

I just tried to build an rpm for my fedora 31 box starting from the https://bodhi.fedoraproject.org/updates/FEDORA-2019-cd4008c5ce
build that you provided recently.
It still crashes when asked to open the example kig file that creates a simple script... however there is a BIG improvement:
kig now works when I create a sample script!  But if I save the resulting construction and load the saved file kig crashes.

I also tried again the original kig-19.08.3-1.fc31.x86_64.rpm rpm just to be sure of the improvement: it does not crash upon creation
of the script, but it crashes as soon as I move the point that I used as argument to the script.
This is the same behaviour as with the upstream compiled kig.

Finally I tried again the result of compiling from sources just to check that it is able to correctly read a kig file with an object constructed via scripting, and it works fine (based on python 2.7).

I hope this helps...

BTW, I should also have write access to the kig code upstream, since I was one of the developpers time ago.  Perhaps if nothing happens
on bugs.kde.org I could just take the chance...

Looks like we need this one, too: https://cgit.kde.org/kig.git/commit/?id=d72f33a14c22480b28c0f35d53293826f6ec787b

So, after looking at the code and the documentation, I suspect the issue is not really the reference count of the tuple itself, but of the individual arguments, which would explain why you do not hit this assertion if the function has no arguments.

(In reply to Kevin Kofler from comment #10)
> Looks like we need this one, too:
> https://cgit.kde.org/kig.git/commit/
> ?id=d72f33a14c22480b28c0f35d53293826f6ec787b

Really?!?  This seems to be a patch to pykig.py, which is 'python-related', but completely
disjoint to python-scripting.  I call it 'outside' scripting: a way to directly produce a kig file
with a construction described in a python script.  It comes handy to generate complex structures
like tassellations or fractals.

Ah OK, thanks for clearing that up. But what is sure is that pykig was not working with the switch to Python 3 and without that patch. :-)

I also applied Franco Pasquarelli's version of the refcount patch and the coordinate precision dialog fix from upstream. I hope that that build will work better, but I have to wait for Koji now, it seems to be completely swamped.

(In reply to Kevin Kofler from comment #13)
> Ah OK, thanks for clearing that up. But what is sure is that pykig was not
> working with the switch to Python 3 and without that patch. :-)

Indeed!!!

> I also applied Franco Pasquarelli's version of the refcount patch and the
> coordinate precision dialog fix from upstream. I hope that that build will
> work better, but I have to wait for Koji now, it seems to be completely
> swamped.

Thank you for your time... it seems that things are now moving :-)  Probably I will
not be able try the new version before Christmas vacation (2nd week of january)

FEDORA-2019-cd4008c5ce has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-cd4008c5ce

FEDORA-2019-cd4008c5ce has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-cd4008c5ce

FEDORA-2019-78e69740a0 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-78e69740a0

Wonderful!  I tried kig-19.08.3-3.fc31.x86_64.rpm against a simple python script and it works! Phew!

kig-19.08.3-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-78e69740a0

kig-19.08.3-3.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cd4008c5ce

kig-19.08.3-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

kig-19.08.3-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.